In compute APIs, they have their schemas in the
independent directory (nova/api/openstack/compute/schemas).
Placement APIs should be like that as well.
This patch separates API schemas to an independent directory
(nova/api/openstack/placement/schemas)
from nova/api/openstack/placement/handlers/resource_class.py.
Subsequent patches will move schemas of other handlers.
Change-Id: I61bfc96953d1158d3204d3f578a5255c18af2d6e
request_spec.instance_group.members is a list of instance UUIDs. It
can get so long that it overflows its TEXT column. This patch changes
request_spec.spec to MEDIUMTEXT.
Change-Id: I6bf0fa19b72887803e77b66698587c2108c9372a
Closes-bug: 1738094
Introducing SchedulerReportClient._get_providers_in_aggregates, a
private method to retrieve the list of resource providers associated
with some number of aggregate UUIDs. Returns the empty list (not None)
if no aggregate UUIDs are specified, or if there are no providers
associated with that aggregate. Logs an error and raises on any
HTTP response other than 200.
This is in anticipation of ComputeDriver.update_provider_tree, which
will need to be supplied a ProviderTree that's fully populated with all
the providers associated with that of the compute node. This includes
all providers in the compute RP's tree *and* those directly associated
via aggregates (but not *their* trees or aggregate associations).
Change-Id: Ia7f95a17fd00bea414459b90adc04a8bf309c396
blueprint: nested-resource-providers
In compute APIs, they have their schemas in the
independent directory (nova/api/openstack/compute/schemas).
Placement APIs should be like that as well.
This patch separates API schemas to an independent directory
(nova/api/openstack/placement/schemas)
from nova/api/openstack/placement/handlers/inventory.py.
Subsequent patches will move schemas of other handlers.
Change-Id: Iab542cfb4d09b26f1d9a3db8a8678a8dba173eb9
In compute APIs, they have their schemas in the
independent directory (nova/api/openstack/compute/schemas).
Placement APIs should be like that as well.
This patch separates API schemas to an independent directory
(nova/api/openstack/placement/schemas)
from nova/api/openstack/placement/handlers/aggregate.py.
Subsequent patches will move schemas of other handlers.
Change-Id: I1b526b1df28c281bd456f35bc0f5c5d9c2464c7e
In compute APIs, they have their schemas in the
independent directory (nova/api/openstack/compute/schemas).
Placement APIs should be like that as well.
This patch separates API schemas to an independent directory
(nova/api/openstack/placement/schemas)
from nova/api/openstack/placement/handlers/trait.py.
Subsequent patches will move schemas of other handlers.
Change-Id: Ieba7ca1e58d931c7cc0b11cb9313d37c5fb7cd3a
In compute APIs, they have their schemas in the
independent directory (nova/api/openstack/compute/schemas).
Placement APIs should be like that as well.
This patch separates API schemas to an independent directory
(nova/api/openstack/placement/schemas)
from nova/api/openstack/placement/handlers/usage.py.
Subsequent patches will move schemas of other handlers.
Change-Id: I38fc7e848fb3f95d79482e5903679e585e3675cc
Similar to I11ba269c3f7a2e7707b2b7e27d26eb7a2c948a82, when
we create a volume attachment with a connector, we need to
also provide the mountpoint via the connector to Cinder,
because internally within Cinder the attachment_create code
is calling attachment_update if a connector is provided.
Change-Id: If3afe8d8bd6b8c327ccc7d1140053bccaf7e1ad7
Closes-Bug: #1737779
The old volume attach flow would pass the mountpoint,
which is the BlockDeviceMapping.device_name, to the
os-attach volume action API. With the new flow, apparently
the mountpoint is expected to be passed to the update
attachment API via the connector dict, which is not obvious
and if not provided, causes Cinder to default the mountpoint
to "/dev/na" which is wrong.
We work around this in Nova by providing the mountpoint in a
copy of the connector dict and pass that to attachment_update,
and update the two places in the code that are updating an
attachment (the normal driver block device attach code and
swap volume). Long-term this should be fixed in the Cinder
attachments update API, but that requires a microversion so
we need to handle it client-side for now.
Change-Id: I11ba269c3f7a2e7707b2b7e27d26eb7a2c948a82
Partial-Bug: #1737779
With change I2f367b06e683ed7c815dd9e0536a46e5f0a27e6c, nova-compute
now unconditionally requires Placement 1.14 to be available (the
client side code doesn't check to see if 1.14 is available before
trying to use it).
This change updates the nova-status check for the minimum required
version of Placement and also starts the "Queens" section of the
Placement upgrade notes docs.
Change-Id: I37415e384d375bc9b548a0223f787a9236286bb0
Add some instructions on how and when to add last-modified headers
when creating a new handler in the placement API.
Change-Id: I8f0c3006d1bb97d228f73256c58a79235cd12670
In relevant requests to the placement API add last-modified
and cache-control headers.
According the HTTP 1.1 RFC headers last-modified headers SHOULD always
be sent and should have a tie to the real last modified time. If we do
send them, we need Cache-Control headers to prevent inadvertent caching
of resources.
This change adds a microversion 1.15 which adds the headers to GET
requests and some PUT or POST requests.
Despite what it says 'no-cache' means "check to see if the version you
have is still valid as far as the server is concerned". Since our server
doesn't currently validate conditional requests and will always return an
entity, it ends up meaning "don't cache" (which is what we want).
The main steps in the patch are:
* To both the get single entity and get collection handlers add
response.cache_control = 'no-cache'
* For single entity add response.last_modified = obj.updated_at or
obj.created_at
* For collections, discover the max modified time when traversing the
list of objects to create the serialized JSON output. In most of
those loops an optimization is done where we only check for
last-modified information if we have a high enough microversion such
that the information will be used. This is not done when listing
inventories because the expectation is that no single resource
provider will ever have a huge number of inventory records.
* Both of the prior steps are assisted by a new util method:
pick_last_modfied.
Where a time cannot be determined the current time is used.
In typical placement framework fashion this has been done in a very
explicit way, as it makes what the handler is doing very visible, even
though it results in a bit of boilerplate.
For those requests that are created from multiple objects or by doing
calculations, such as usages and aggregate associations, the current time
is used.
The handler for PUT /traits is modified a bit more extensively than some
of the others: This is because the method can either create or validate
the existence of the trait. In the case where the trait already exists,
we need to get it from the DB to get its created_at time. We only do
this if the microversion is high enough (at least 1.15) to warrant
needing the info.
Because these changes add new headers (even though they don't do
anything) a new microversion, 1.15, is added.
Partial-Bug: #1632852
Partially-Implements: bp placement-cache-headers
Change-Id: I727d4c77aaa31f0ef31c8af22c2d46cad8ab8b8e
The placement API GET / is for version discovery. Skip authentication
on this URL.
The change to test_deploy is required to make it request a URL that
requires authentication. It had been using /.
Change-Id: I5ed1f7a607620c43671e90eaf8a1f6285f1d15e4
Closes-Bug: #1733630
This will be used by instance action pagination API.
Add limit/marker/filters support to get_by_instance_uuid of
InstanceActionList object, also add limit/marker/filters support to
actions_get method of db.
Part of blueprint pagination-add-changes-since-for-instance-action-list
Change-Id: Ic7dd6480a4b250ae6529d94ee0386b5e95b0ca04
When we do some operation on instances, will record some
instance action(such as 'create') in 'instance_actions' table,
and some sub-event will record(such as
compute__do_build_and_run_instance) in 'instance_actions_events'
table.
we need update the instance action's updated_at when instance
action events are created and instance action created or finished.
Change-Id: I75a827b759b59773c08ffc6b1e3e54d6189b5853
Closes-Bug: #1719561
It is a follow-up for I4db74e4dc682bc03df6ec94cd1c3a5f5dc927a7b.
Fix description of placement microversion 1.14.
Change-Id: I7a7ffc395d444fe7cf0434ea6745dde0dae11ad5
blueprint nested-resource-providers
This is a follow up to another patch [1] that removed the old-style
quotas code which is no longer in use. Here, we remove the 'reserved'
key from quotas internally and set it in the APIs where it's expected.
We also remove code that accesses the quota_usages and reservations
tables as they're no longer used.
[1] https://review.openstack.org/#/c/511689
Change-Id: I75291571468ddb79b7561810de0953bb462548e3
These are written in preparation for follow up old-style quotas code
removal that moves the logic for the 'reserved' field from the quota
internals (where it's no longer used) to the API (where it's expected
to be provided until we have a new microversion). These tests will
help catch any unintended change in behavior.
Change-Id: I1f743a8db7d032e09372587622ab64250a05e0f0
When a resource provider is created an ObjectActionError can
happen. The API handler for POST /resource_provider catches
this and sends out an error response. Prior to this change the
response only identified the resource provider by uuid. Since
it is possible to create a resource provider by only providing
a name, this error response may not be super useful.
This change adds the name of the proposed resource provider to
the message, to make sure things are clear.
However, it's worth noting that at the current time most
situations which would cause an ObjectActionError are not
possible from the API code path: they are caught by the
JSONSchema validation. The one clear path that is not caught,
and thus is the place where a validation of the response has
been done in a gabbit, is when a resource provider tries to
set its parent uuid to its own uuid. In order for the caller
to do this, the caller has to know its own uuid, so the
ambiguity problem is moot.
As we might make additional changes in the future, adding
the name seems the most flexible thing to do, so here it
is.
Change-Id: I7fee5344fc7cb2e4ba3f46e192ba0122edeb0605
Closes-Bug: #1735405
The 'Location' parameters are missing in the follwoing APIs of
Placement API reference. So add them.
* POST /resource_providers
* POST /resource_classes
* PUT /resource_classes/{name} (microversion 1.7-)
* PUT /traits/{name}
Change-Id: Ieed5cb7d4697472ab46b2e80d6d2df68098c5631
Closes-Bug: #1733329
This change integrates support of the Cinder 3.44
volume attachment API.
The patch bumps the compute service version to
check whether all the compute nodes are upgraded to the
version that can handle attach and detach with the new
flow.
To enable the new flow we also need the 3.44 or higher
microversion from Cinder. We check that in the API and
if it's not available we fall back to the old
attach/detach flow.
Co-Authored-By: Ildiko Vancsa <ildiko.vancsa@gmail.com>
Partially Implements: blueprint cinder-new-attach-apis
Change-Id: Ifc01dbf98545104c998ab96f65ff8623a6db0f28
Introducing SchedulerReportClient._get_providers_in_tree, a private
method to retrieve the list of resource providers associated with one
provider UUID. Returns the empty list (not None) if there's no provider
with the specified UUID. Logs an error and raises an exception on any
HTTP response other than 200.
Change-Id: Ifcaa1c9c0432af17ccc91a8bf0a85e37c9b00de5
blueprint: nested-resource-providers
This commit deprecates the config option and policy
for hide server address. They are marked for removal.
Implement blueprint remove-configurable-hide-server-address-feature
Depends-On: I6aed4909b0e7efe9c95d1f7398db613eca05e5ce
Change-Id: I6040e8c2b3e132b0dfd09f82ae041b4786a63483
Adds a new microversion (1.14) to the placement REST API for supporting
nested resource providers.
For POST /resource_providers and PUT /resource_providers/{uuid}, a new
optional 'parent_provider_uuid' field is added to the request payload.
For GET /resource_providers/{uuid} responses, the
'parent_provider_uuid' field and a convenience field called
'root_provider_uuid' are provided.
For GET /resource_providers, a new '?in_tree=<rp_uuid>' parameter is
supported. This parameter accepts a UUID of a resource provider. This
will cause the resulting list of resource providers to be only the
providers within the same "provider tree" as the provider identified by
<rp_uuid>
Clients for the placement REST API can specify either
'OpenStack-API-Version: placement 1.14' or 'placement latest' to handle
the new 'parent_provider_uuid' attribute and to query for resource
providers in a provider tree.
Change-Id: I4db74e4dc682bc03df6ec94cd1c3a5f5dc927a7b
blueprint: nested-resource-providers
APIImpact
