An empty value for the 'all_tenants' query parameter of '/servers' and
'/servers/detail' means the value defaults to 'True', i.e. requesting
'/servers?all_tenants' is the same as '/servers?all_tenants=1'. Clarify
this, since the current wording is confusing.
Change-Id: Ib5fdd3b73aa5179e0379ee8f465e4118107786be
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Closes-Bug: #1909745
Introduce API microversion 2.88, which makes the following changes to
a number of 'os-hypervisors'. Specifically, the following fields are
dropped from both the '/os-hypervisors/detail' (detailed list) and
'/os-hypervisors/{hypervisor_id}' (show) APIs:
- current_workload
- cpu_info
- vcpus
- vcpus_used
- free_disk_gb
- local_gb
- local_gb_used
- disk_available_least
- free_ram_mb
- memory_mb
- memory_mb_used
- running_vms
In addition, the '/os-hypervisors/statistics' API, which provided a
summary of the above stats but for all hypervisors in the deployment, is
dropped entirely.
Finally, the '/os-hypervisors/{hypervisor}/uptime' API, which provided a
similar response to the '/os-hypervisors/{hypervisor}' API but with an
additional 'uptime' field, has been removed in favour of including this
field in the primary '/os-hypervisors/{hypervisor}' API.
A small tweak to 'tox.ini' that allows us to share some venvs is
included.
Part of blueprint modernize-os-hypervisors-api
Change-Id: I515e484ade6c6455f82a3067940a418a0d7d965a
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
The 'availability_zone' description in unshelve api-ref is confusing,
adding NOTE for unshelve request body:
Since microversion 2.77, allowed request body schema are {"unshelve":
null} or {"unshelve": {"availability_zone": <string>}}. A request body
of {"unshelve":{}} is not allowed.
Closes-Bug: #1908336
Change-Id: I66c209baf11c37ffebca52764263daae9e1dd50b
This change adds some basic notes in the api-ref for a wrinkle in the
current os-volume_attachments API in that both attach and detach actions
are async, returning to the caller *before* the underlying action is
complete. As such callers need to make seperate calls to ensure these
actions complete successfully.
There are also currently two different ways of polling for completion
when attaching and detaching.
- When attaching callers should use the volume status and list of
attachments as reported by the volume API.
- When detaching callers should instead use the list of volume attachments
reported by the os-volume_attachments API.
This is due to the way in which Nova currently completes the attachment
via c-api last during attachment and deletes the bdm record last during
detachment.
It would be useful to one day centralise on just using the
os-volume_attachments API to poll both actions but to do that we would
need to start tracking our own state within the BDMs.
Change-Id: Id367ee53ef1458b6a90fc107ab14f5b3cbba7a86
Nova's `os-simple-tenant-usage` has the following statement.
```
Reports usage statistics of compute and storage resources periodically
for an individual tenant or all tenants. The usage statistics will
include all instances’ CPU, memory and local disk during a specific
period.
```
To some people, when reading that, they might get the understanding that
the `os-simple-tenant-usage` will report the actual use of resources.
Therefore, if a VM is stopped and then started back again, it (the
`os-simple-tenant-usage`) would only report the time the VM has been up
and running. However, that is not what happens. The
`os-simple-tenant-usage` reports the time that a virtual machine (VM)
exists in the cloud environment. Therefore, actions such as pause,
suspend, and stop do not affect the usage accounting.
This might be a problem for people using this API for billing, or for
people that use other systems (e.g. CloudKitty) for billing.
End-users might try to cross-check the data from the billing from
CloudKitty for instance, with the usage report found in Horizon that
uses this API, and the numbers will not add up, as people might only
consider the time a VM has been up and running to charge users in
CloudKitty.
An extension was proposed in [1], to allow operators to customize
the usage accounting. However, during a meeting with the community [2],
the extension was rejected for two reasons:
* Nova tries to avoid using config driven APIs. Meaning, APIs that change
the response according to server-side configurations;
* The community has decided to get rid of usage and billing accounting
in Nova.
Having said that, we would like to propose a documentation amendment.
The idea is to explicitly say for users/operators that the simple usage
API only considers the time that the VM existed in the cloud for the
accounting, and not the actual time it has been up and running.
This will save some misunderstanding and misuse of the API data.
References
===========
[1] https://review.opendev.org/c/openstack/nova/+/711113
[2] http://eavesdrop.openstack.org/meetings/nova/2020/nova.2020-12-03-16.00.log.txt
Closes-Bug: #1907133
Change-Id: Ic55669f5210b57f151f693393f205655765a8dc9
This one is tied into an admin action in the server actions API, which
means we must remove that API action also. Otherwise, this isn't too
crazy.
Change-Id: I58343b94b67915062d044fa0f53aeab01b77738f
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Follow up for change I9512f605dd2b3b0e88c951ed086250d57056303d.
Change-Id: Ia627bab8ed911baf329e0bda385beb2ffcbbe7d6
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
This was only useful with XenAPI and can therefore be removed.
Change-Id: I9512f605dd2b3b0e88c951ed086250d57056303d
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Remove references to the feature from various comments scattered
throughout the code.
Change-Id: Ic353a2489389c557859c249218eaf6060974e1a9
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Previously disk_bus values were never validated and could easily end up
being ignored by the underlying virt driver and hypervisor.
For example, a common mistake made by users is to request a virtio-scsi
disk_bus when using the libvirt virt driver. This however isn't a valid
bus and is ignored, defaulting back to the virtio (virtio-blk) bus.
This change adds a simple validation in the compute API using the
potential disk_bus values provided by the DiskBus field class as used
when validating the hw_*_bus image properties.
Closes-Bug: #1876301
Change-Id: I77b28b9cc8f99b159f628f4655d85ff305a71db8
Change pygments_style to 'native' since old theme version always used
'native' and the theme now respects the setting and using 'sphinx' can
lead to some strange rendering.
Change-Id: Icd9d529dbe66626ac53a9fdca5bc6821998a0b7d
Switch to openstackdocstheme 2.1.2 and reno 3.1.0 versions. Using
these versions will allow parallelizing building of documents.
Update Sphinx version as well.
openstackdocstheme renames some variables, so follow the renames. A
couple of variables are also not needed anymore, remove them.
Set openstackdocs_auto_version to not version the documents.
Set openstackdocs_auto_name to use project as name.
Depends-On: https://review.opendev.org/728432
Change-Id: I4e3ae3ceabe125ea459ed4baabf2e98686268e50
These were previously not listed but are important to re-enforce to
avoid corruption of instances during an evacuation.
Change-Id: Ia80dba0ade98940a5c4f94a9d2095e3c9ef21f97
Allow PUT /servers/{server_id}/os-volume_attachments/{volume_id}``
to support specifying ``delete_on_termination`` field in the request
body. This allows updating the attached volume's flag that controls
whether or not it is automatically deleted when the instance is deleted.
When we request 'volumeId' and 'delete_on_termination' in the requst
body to swap volume, since the new microversion it will be support
updating the swapping volume's delete flag.
Co-Authored-By: Dan Smith <dansmith@redhat.com>
Blueprint: destroy-instance-with-datavolume
Change-Id: I6ccac4e17f56b40e67c79d40f32558ef414685ea
Microversion bump to allow non-admin user to use more filters key
when listing instances.
In order to stay coherent, all existing instance filters who are
related to a field readable by default to non admin users when showing
instance details, should be allowed by default without policy
modification.
Implements: blueprint non-admin-filter-instance-by-az
Change-Id: Ia66d3a1ceb74ed521cf44922929b2a502f3ee935
We have a custom of naming the directory after the API. Reinforce that
here.
Change-Id: I5bf68aacc1d987400a91467835c4b55f03c18beb
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
APIImpact: Adds 2.82 microversion for /os-server-external-events API.
DocImpact: Adds new version to doc/api_samples/versions/.
Change-Id: I7a626544d8221dc0eeb5672986ca897ce4718be8
Blueprint: nova-cyborg-interaction
As highlighted in I77b1cfeab3c00c6c3d7743ba51e12414806b71d2, filtering
either floating IPs or floating IP pools by floating IP name will
actually fallback to filtering by ID. Update the API ref to reflect
this.
Change-Id: I00443ae111cbd1e1ec4d2c2ae1828ddaa095fd1a
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
This legacy service is no longer used and was deprecated during the
Stein cycle [1]. It's time to say adios and remove them in their
entirety. This is pretty straightforward, with the sole exception of
schema for the 'remote-consoles' API, which has to continue supporting
requests for type 'xvpvnc' even if we can't fulfil those requests now.
[1] https://review.opendev.org/#/c/610076/
Part of blueprint remove-xvpvncproxy
Depends-On: https://review.opendev.org/695853
Change-Id: I2f7f2379d0cd54e4d0a91008ddb44858cfc5a4cf
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
This disambiguates the description on the server.image parameter.
If the server is booted from volume (where boot from volume means
there is a bdm with boot_index=0 and destination_type=volume),
then the server.image will be an empty string [1] otherwise it
will be a dict.
[1] 2f0f8b8cf1/nova/api/openstack/compute/views/servers.py (L540)
Change-Id: Ia1ecd39a5636fa5a35cdbcafc03828b2925a9033
The flake8 hook for pre-commit installs its own flake8 which is
not what hacking is pinned to. This results in a bunch of errors.
By doing a local hook we can cause these to be the same.
There are flake8 exclusions in tox.ini that need to be used
in pre-commit. Also we should exclude svg files from the whitespace
modifications, because who cares.
Once those are fixed, running pre-commit -a fixes some whitespace
issues. While the normal use isn't to run -a - if someone does make
a patch that touches any of these they'll get erroneous unrelated
errors compared to their lower work - so fix all of the existing
issues, which are mostly space-at-end-of-line issues it seems.
Change-Id: I78e753492e99c03b30a0a691db3bd75ee3d289c9
The POST /os-server-external-events API had the following confusing
behavior:
With multiple events in the payload, if *some* (but not all) were
dropped, the HTTP response was 207, with per-event 4xx error codes in
the payload. But if *all* of the events were dropped, the overall HTTP
response was 404 with no payload. Thus, especially for consumers sending
only one event at a time, it was impossible to distinguish e.g. "you
tried to send an event for a nonexistent instance" from "the instance
you specified hasn't landed on a host yet".
This fix gets rid of that sweeping 404 condition, so if *any* subset of
the events are dropped (including *all* of them), the HTTP response will
always be 207, and the payload will always contain granular per-event
error codes.
This effectively means the API can no longer return 404, ever.
Closes-Bug: #1855752
Change-Id: Ibad1b51e2cf50d00102295039b6e82bc00bec058
This exposes the 'nova-console' service via a REST API, a service that
can only be used with XVP VNC consoles, which in turn require the
'nova-xvpvncproxy' service. We we would like to remove the
'nova-console' and 'nova-xvpvncproxy' services, so start here.
Part of blueprint remove-xvpvncproxy
Change-Id: I2ee3b8c44e5d85e9b3c811ed3c5e6cddc563054f
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
Like '/os-networks', we can't remove this in its entirety due to the
fact that some of these are proxy URLs that also work with neutron.
These are retained but everything else is nuked.
Note that this highlights a bug in the API, whereby a missing
'objects.Network.cidr' value results in a value of 'None' being output
over the API. Clearly this is incorrect, but it's probably not worth
fixing for this deprecated API.
Change-Id: I31cb0891144bdd7945479bb6692b0a533de4c5d0
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
Drop support for most of the 'os-networks' REST APIs excluding those
that proxy through to neutron.
This API now returns a 410 response for the non-proxy routes.
Unit tests are removed for removed APIs and the functional API sample
tests are just asserting the 410 response now same. The latter are also
expanded to cover APIs that weren't previously tested.
The API sample docs are left intact since the API reference still builds
from those and can be considered more or less branchless, so people
looking at the API reference can apply it to older deployments of nova
before these APIs were removed.
Note: yes, the API samples are correct. It really is a useless API when
used with neutron.
Change-Id: I68bfa77a520382317fc490a4f6c12dd62fc6dcda
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
This is a nova-network-only API. As with previously removed APIs, this
API now return a 410 response for all routes.
There are some DB methods that were only used by this API. They will be
removed separately in a future change.
Change-Id: Iaa7fb6c548613164d33793822ee85339f9f7fefb
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
This builds on I0bd63b655ad3d3d39af8d15c781ce0a45efc8e3a
which made DELETE /os-services/{service_id} fail with a 409
response if the host has instances on it. This change checks
for in-progress migrations involving the nodes on the host,
either as the source or destination nodes, and returns a 409
error response if any are found.
Failling to do this can lead to orphaned resource providers
in placement and also failing to properly confirm or revert
a pending resize or cold migration.
A release note is included for the (justified) behavior
change in the API. A new microversion should not be required
for this since admins should not have to opt out of broken
behavior.
Change-Id: I70e06c607045a1c0842f13069e51fef438012a9c
Closes-Bug: #1852610
Two things here:
1. The API guide was missing the hyper-v driver which supports
the suspend operation. Rather than hard-code a list of supported
drivers in the doc, this change just links to the entry in the
feature support matrix.
2. The supported hypervisors mention in the API reference is removed
because the end user using the API should not need to know or care
what backend hypervisor on which their server is running. They can
either suspend or not, but we don't need to mention the supporting
drivers for that in the API reference.
Change-Id: Ib76779a8e34b2c68b0f4af190f71576180360d0f
Related-Bug: #1815403
The 'device' response parameter is not included in
GET /servers/{server_id}/os-volume_attachments or
GET /servers/{server_id}/os-volume_attachments/{volume_id}
when the BDM doesn't have a device_name set, which can be the
case with a volume attached to a shelved offloaded server.
Also, see the logic in _translate_attachment_detail_view
and _translate_attachment_summary_view. This simply marks
the response parameter as optional in those APIs. Since
the parameter is optional, it is sorted to after the required
parameters but before the parameters added in new microversions.
Change-Id: Ifda2f7983f349d51d97e5621cac6c5ad9cb0295f
Closes-Bug: #1818345
The description of "SUSPENDED" server status was misguiding. Rewording
it to make it more accurate.
Change-Id: Ie93b3b38c2000f7e9caa3ca89dea4ec04ed15067
Closes-Bug: #1815403
This is a follow up to [1] and borrows the same wording
from the resize action post-conditions except uses
"migrate(d)" instead of "resize(d)" where appropriate.
[1] I77830dfb738cd78c830dc3ce7ea88216c1eac7ef
Change-Id: Id24cb48b1b70848d2ce7020d114a843c509ab81c
The info of Delete (Abort) on-going live migration is missing
in support matrix, it could be useful for users to consider
using this feature.
This patch adds it.
Change-Id: I2f917627fa451d20b1fd1ff35025481a4e525084
Closes-Bug: #1808902
This change does a few things:
1. Moves the post-condition paragraph into an
"Asynchronous Postconditions" section like other
API references.
2. Drops the "RESIZED" VM status wording since what
that probably meant was the server OS-EXT-STS:vm_state
value would be "resized" but what was in the reference
was (a) wrong and (b) redundant with the VERIFY_RESIZE
status.
3. Re-words and links the resize_confirm_window config
option wording since saying "if you set" a config option
in the API reference does not really make sense since
"you" (the non-admin cloud user) does not have control
over how the cloud is configured.
Change-Id: I77830dfb738cd78c830dc3ce7ea88216c1eac7ef
It's a long known issue that resize does not resize ephemeral
disks attached to the server yet we continue to get bugs about
it and there is no one working on fixing it. As such this change
adds a note to the API reference for the resize server action API
mentioning the known limitation.
Change-Id: I31ca3627f2d3ef5a8db5eecf3759cd304b059963
Related-Bug: #1558880
This adds a new microversion and support for requesting image pre-caching
on an aggregate.
Related to blueprint image-precache-support
Change-Id: I4ab96095106b38737ed355fcad07e758f8b5a9b0
