In the following resource class APIs,
the name of a resource class must start with 'CUSTOM_'.
If not, the request returns a 'Bad Request (400)' response code.
It should be described in the API reference. So add it.
* POST /resource_classes
* PUT /resource_classes/{name}
Change-Id: I132c532678bb74a460515067187fbf1e30885335
Closes-Bug: #1733308
Optional parameters should be after required paramenters.
Parameters added in microversions should be after
original parameters.
So fix them.
Change-Id: I5e3f5df5601d3747debed273e09a8b9b18046a96
Closes-Bug: #1728557
Currently when providing existing direct port, nova-compute
will overwrite the binding-profile information with pci_vendor_info
and pci_slot. The binding-profile will be used to request
NIC capabilities for SR-IOV ports [1]. This also allows to distinguish
which neutron mechanism driver will bind the port [2].
This patch updates the behaviour that on update port it will update,
rather than overwrite, the binding-profile information with
pci_vendor_info and pci_slot. And on unbind port it will remove
only the pci_vendor_info and pci_slot from the port binding-profile
rather than unsetting the entire field.
[1] https://review.openstack.org/#/c/435954/
[2] https://review.openstack.org/#/c/499203/
Closes-Bug: #1719327
Change-Id: Id847949b4761d51a14e5c2f39552f60a47889aa9
In a new microversion, 1.12, include project_id and user_id in the
output of GET /allocations/{consumer_uuid} and add JSON schema
to enable PUT to /allocations/{consumer_uuid} using the same dict-based
format for request body that is used in the GET response. In later
commits a similar format will be used in POST /allocations. This
symmetry is general good form and also will make client code a little
easier.
Since GET /allocation_candiates includes objects which are capable
of being PUT to /allocations/{consumer_uuid}, its response body has
been updated as well, to change the 'allocation_requests' object
to use the dict-based format.
Internally to handlers/allocation.py the same method (_set_allocations)
is used for every microversion. Any previous data structure is
transformed into the dict-ish form. This means that pre-existing tests
(like allocation-bad-class.yaml) continue to exercise the problems it
was made for, but needs to be pinned to an older microversion, rather than
being latest.
Info about these changes is added to placement-api-ref,
rest_api_version_history and a reno.
Change-Id: I49f5680c15413bce27f2abba68b699f3ea95dcdc
Implements: bp symmetric-allocations
Closes-Bug: #1708204
The service token feature is no longer considered experimental. This
change set rewords the help strings in the service_token conf
accordingly (fixing some typographical issues at the same time).
Change-Id: Ibaf06ff4f19283544de720b0b5f01ddf655b0b46
Change the Adapter loading for glance to use the auth from the user
context instead of exposing and requiring it in the conf. With this
change, it is possible to leave the [glance] conf section empty and
still be able to discover the image API endpoint from the service
catalog.
Note that, when we do this, we often end up with the user auth being a
_ContextAuthPlugin, which doesn't conform to the characteristics of
keystoneauth1.identity.base.BaseIdentityPlugin as augmented in
keystoneauth1 3.1.0. This requires a series of workarounds until bug
1709118 is fixed. These, along with workarounds for bugs 1707993 and
1707995, are subsumed with this change set in a (hopefully temporary)
helper method nova.utils.get_endpoint.
This lays the foundation for other services that should use user
context for authentication - those via which Nova is acting on behalf
of the user, i.e. cinder, keystone, and (sometimes) neutron[1].
(Services such as placement and ironic (and sometimes neutron) should
continue to use admin auth context loaded from the conf.)
[1] bb4faf40df/nova/network/neutronv2/api.py (L149-L160)
Co-Authored-By: Eric Fried <efried@us.ibm.com>
Partial-Implements: bp use-ksa-adapter-for-endpoints
Change-Id: I4e755b9c66ec8bc3af0393e81cffd91c56064717
Some pGPUs (e.g. NVIDIA GRID K1) support different vGPU types. User can
use `enabled_vgpu_types` to specify the enabled vGPU types that a guest
could consume from the host.
NOTE(sbauza) :
Since that configuration is shared between all virt drivers, we need to
provide a single change that will just add that conf opt and then use
it in separate series as a common base. That implies that configuration
option is useless until we merge the code that reads it, but that's a
necessary compromise for making sure we can move both Xen and libvirt
efforts in parallel.
Partially Implements: blueprint add-support-for-vgpu
Co-Authored-By: Sylvain Bauza <sbauza@redhat.com>
Change-Id: I56f9597e968eac041832cdb90fe52cf0d3b4a4ef
This patch aims at deleting the records of the archived instances from
the instance_mappings and request_specs tables in the API database
immediately following their archival from instances to shadow_instances
table. So upon running the 'nova-manage db archive_deleted_rows' command
the records of the archived instances will be automatically removed from
the instance_mappings and request_specs tables as well. A warning has
also been added to fix the issue of 'nova-manage verify_instance'
returning a valid instance mapping even after the instance is deleted.
The patch also adds InstanceMappingList.destory_bulk() and
RequestSpec.destroy_bulk() methods for ease of bulk deletion of records.
Change-Id: I483701a55576c245d091ff086b32081b392f746e
Closes-Bug: #1724621
Closes-Bug: #1678056
The arguments of nova CLI commands related to host aggregate
(I93f44a12b6d5a91b448f6f8d238311d58bf40c01) are fixed.
The host APIs have been deprecated since microversion 2.43.
So remove description related to nova host commands.
And add description about nova hypervisor commands.
Change-Id: Ibf78865844da6f007b610f12430df4866076f00b
Closes-Bug: #1726658
This will be used by the migration_get_all_by_filters
method which will later be used by the MigrationAPI to
support the migrations pagination.
Part of blueprint add-pagination-and-change-since-for-migration-list
Change-Id: I12c5babaec3a09dd0c6fbb5b77060a352ea373e7
Briefly document in the Placement API reference:
a) the use of Content-Type: application/json
b) how to use microversion headers, including a link to the main
Microversions reference.
Change-Id: I60d7b9dfe4f1c50fc50eaf07a04848c220ffcf62
The GET /os-migrations API and migration_get_all_by_filters
DB API method are not actually filtering migrations by status. The API
will only do that if the user requests the migrations to be filtered by
status using query paramters to the REST API.
The docstrings related to this were confusing since the
GET /servers/{server_id}/migrations REST API *will* filter by
in-progress status.
Change-Id: Ie9c500ae62c23930bdb8f5700dbdb9f149105e9a
The testing strategy doc was linking to the hacking repo docs
on creating unit tests, which are very specific to creating
unit tests for hacking rules.
This changes the link to the 'creating unit tests' section in
the HACKING.rst file, which has more information on testing
within nova.
Along with that change, the HACKING.rst testing section is
updated a bit to point out that we use stestr now instead of
testr and adds a proper link to the development environment
quickstart docs.
The nova/tests/unit/README.rst actually needs a lot of work,
but that's left for another day.
Change-Id: Ie5106d87d632286162b31ce132e947c306d21abd
Closes-Bug: #1732024
AllocationCandidates.get_by_filters used to take a `filter` parameter, a
dict with one member, 'resources'. Looking toward granular resource
requests (and other things like limiting the number of results), this
change set reworks the method (and its down-stack callees) to be named
get_by_requests. These now accept a `requests` parameter, which is a
list of RequestGroup instances parsed from the querystring via
parse_qs_request_groups.
The current patch is just a refactor. There is no API change, so the
schema will not allow anything other than the `resources` member of the
shared (use_same_provider=False) RequestGroup to come through. That
member is extracted and passed down the line, resulting in no functional
change.
Change-Id: I8d7ccf56aa75d9183626f736b62fba62e239a826
blueprint: granular-resource-requests
This reverts commit ee7858ffcaf3f874feb0ea0c68871f2c93254fdd.
Looks like heat gate is broken with this change, and the
revert fixes it. Tested with https://review.openstack.org/#/c/518834/
Change-Id: I3fefcda93e496e97474bd419d50bd9753a4d1fed
Closes-Bug: #1731395
Currently when providing existing direct port, nova-compute
will overwrite the binding-profile information with pci_vendor_info
and pci_slot. The binding-profile will be used to request
NIC capabilities for SR-IOV ports [1]. This also allows to distinguish
which neutron mechanism driver will bind the port [2].
This patch updates the behaviour that on update port it will update,
rather than overwrite, the binding-profile information with
pci_vendor_info and pci_slot. And on unbind port it will remove
only the pci_vendor_info and pci_slot from the port binding-profile
rather than unsetting the entire field.
[1] https://review.openstack.org/#/c/435954/
[2] https://review.openstack.org/#/c/499203/
Closes-Bug: #1719327
Change-Id: I80106707a037d567d0f690570f2cf9cfcd30d594
If an incoming request to placement does not set the accept header
force it to 'application/json'. This not only ensures that error
responses are in JSON but also that errors early in the middleware
stack do not cause a key error (see the #1724065 bug).
This fix is done by checking headers early in the middleware stack
using the requestlog middleware as a convenient place to do the
check. This overloads requestlog's purpose, but avoids adding yet
more middleware (doing so has some small impact per request).
Fixing bug 1724065 fixes a 500. Fixing bug 1674694 changes (for some
requests) the content type of the bodies of 400-499 responses. This
creates a bit of quandry for microversion handling. If a microversion
is considered required here then it's not clear the global fix is
worth doing and the 500 fix should be limited the microversion
middleware. The intent all along has been that responses should
strive to align with the API-WG errors guideline [1], which assumes
application/json.
[1] http://specs.openstack.org/openstack/api-wg/guidelines/errors.html
Change-Id: Ice27c7080fc2df097cb387f7438c0aaf32b4c63d
Closes-Bug: #1724065
Closes-Bug: #1674694
This adds the description attribute to the Flavor object
and the accompanying database schema upgrade.
This is the first field on a flavor that we've allowed
to be updated, so it requires some new plumbing for doing
an update on the flavor record itself during save(). The
updateable fields are whitelisted so we don't leak other
updates in here, like name, flavorid, vcpus, etc.
As part of this change, we also have to be sure to not
persist the description in the embedded instance.flavor
since (1) it's a large field and (2) we are not going
to expose the instance.flavor.description out of the
servers API.
Versioned notifications will be handled in a later change.
Part of blueprint flavor-description
Change-Id: I6db4eb46df0d7ec025b969a46621823957503958
In anticipation of accepting numbered groupings in placement's GET
/allocation_candidates API, this change adds a util method to parse a
single traits list query parameter value; and another to parse an entire
querystring into a list of RequestGroup instances.
Change-Id: I720630155e9aa53e049e932b9722aaa4ff4247db
blueprint: granular-resource-requests
This change introduces a new module, nova.api.openstack.placement.lib,
with a class RequestGroup, which is to be used both by the placement API
internally (when parsing the querystring to GET /allocation_candidates)
and nova (when parsing extra_specs and producing said querystring for
said API).
The decision to put this into a placement-specific package is
deliberate: when placement gets split out, this should go with it, so it
can be imported by any placement API consumer. In the meantime, we
accept that it will feel a little weird for nova code to import from a
placement API package; but this should be the only module for which that
happens - i.e. any other "shared" classes/utils should go in this same
module.
Change-Id: I8a70347d06d032788d27d1af8967a65d530c15fe
blueprint: granular-resource-requests
The functional test mock assume args[-1] always be instance_uuid
but actually it's not, when _save_db it might contains some changes
on the instance_mapping.
some test functions were reused in order to avoid display warning.
Change-Id: I90afca7f426f5c9fd14051df6fb0a8b45cd0833d
Closes-Bug: 1718325
I put out a new placement microversion [1] and initially missed updating
the API reference documentation [2]. I'd like to say it would have
helped if the checklist in the Microversion section of the contributor
doc had been up to date, except I didn't even know about that document
at the time. Anyway, this change set adds that bullet - and I'll know
to refer to it next time.
[1] https://review.openstack.org/499826
[2] https://review.openstack.org/515748
Change-Id: Id0329d9824eeb1d210defe0567286372b72cb1cf
If a gabbi file sets a default microversion by setting a header
'OpenStack-API-Version' with a value like 'placement latest' and then
later overrides that in an individual test with a header of
'openstack-api-version' the difference in case can lead to failure.
In the best case the failure is consistent.
In the worst case it can sometimes work, because the header shows up
twice in the request, and the last header wins, order in the headers
and the resulting list dependent on the vagrancies of python ordering.
The solution is to always use the same case, so this change updates
all use to be lowercase, to establish a precedent that future people
will be able to use as an example.
Note that gabbi is case sensitive here in part because of the
implementation but also because it provides the control and possibility
to test exactly this problem.
Change-Id: I1e89e231cf0d46d211d360cda091b33520f85027
Closes-Bug: #1728934
