The placement API reference documentation for POST /resource_classes [1]
said:
The new class must be a custom resource class, prefixed with CUSTOM_ and
distinct from the _standard_ resource classes.
...where _standard_ was a link to os-traits documentation [2]. Since we
don't have os-resource-classes (yet), this change set removes that
linkitude.
[1] https://developer.openstack.org/api-ref/placement/#create-resource-class
[2] https://docs.openstack.org/os-traits/latest/
Change-Id: I15fbed460598b7d603eca48cbaecf1036906f6c7
Closes-Bug: #1747095
Originally, in change Id188d48609f3d22d14e16c7f6114291d547a8986 we
added a re-initialization of volumes, encryptors, and vifs to hard
reboot. When creating the libvirt domain and network, we were waiting
for vif plug events from neutron when we replugged the vifs. Then, we
started seeing timeouts in the linuxbridge gate job because compute
was timing out waiting for plug events from neutron during a hard
reboot.
It turns out that the behavior of neutron plug events depends on what
vif type we're using and we're also using a stale network info_cache
throughout the hard reboot code path, so we can't be 100% sure we know
which vifs to wait for plug events from anyway. We coincidentally get
some info_cache refreshes from network-changed events from neutron,
but we shouldn't rely on that.
Ideally, we could do something like wait for an unplug event after we
unplug the vif, then refresh the network_info cache, then wait for the
plug event. BUT, in the case of the os-vif linuxbridge unplug method,
it is a no-op, so I don't think we could expect to get an unplug
event for it (and we don't see any network-vif-unplugged events sent
in the q-svc log for the linuxbridge job during a hard reboot).
Closes-Bug: #1744361
Change-Id: Ib0cf5d55750f13d0499a570f14024dca551ed4d4
The tests for allocation_candidates query parameters in test_report.py
relied on urlencode with a dict arg to create the expected_url that is
compared with the actual URL that the report client creates when
communicating with the placement service.
This is risky because the ordering of the query parameters is
not reliable when the source data is a dict. This change expands
the tests where it was used to do more explicit comparisons.
Change-Id: I2e51a4574b20c0634ad83a53c0e68261bbf0ac82
Closes-Bug: #1747001
This adds a mention of the nova-scheduler service requiring
placement 1.17 and also links to the placement upgrade notes
from the more general upgrade notes, since we are now firmly
in a place where placement needs to be upgraded before nova.
Since we consider placement global, this removes the 1.14
note about nova-compute since we assume that if you're going
to upgrade placement to get 1.17 for the scheduler, and control
services should be upgraded before computes, then the computes
are going to get a new enough placement service automatically.
Change-Id: I06937c7642dca4a1932cbbf46569acc9c58e44a6
This adds a couple of functional tests for the end-to-end
flow of creating a server with a flavor that has a required
trait. Each test has two computes. One test covers the case
of a successful placement on a compute that has a trait where
the other compute doesn't. The other test covers the case that
none of the computes have the required trait so the server
create request fails.
Part of blueprint request-traits-in-nova
Change-Id: Iacb9808ef7188e3419abfac9e8c5fb5a46c71c05
This is a follow up to Ie039322660fd0e2e0403843448379b78114c425b.
A few things are changed here:
* The note about using file injection is removed. File injection
was deprecated in the API in Queens and not something that we
really want users using.
* Mention that creating a flavor is typically admin-only.
* Link to the BDM docs for more details about BDM parameter values.
* Update the manage-ip-address docs to make the examples rely on
using the networking resource CLIs rather than any proxy APIs
that were available in nova.
Change-Id: Ifa2e2bbb4c5f51f13d1a5832bd7dbf9f690fcad7
This imports the "launch instance" end user guide docs from
the openstack-manuals repo. As part of the docs migration
in Pike, these were forgotten. The copied contents come from
the stable/ocata branch of openstack-manuals, and therefore
likely need some updating, but that could be done in follow up
changes. This is an initial import to (1) publish the content
again somewhere and (2) fix broken links in the cinder docs
for booting from volume.
Change-Id: Ie039322660fd0e2e0403843448379b78114c425b
Partial-Bug: #1714017
Related-Bug: #1711267
This makes us pass an upper limit to placement when doing scheduling
activities. Without this, we'll always receive every host in the
deployment (that has space for the request), which may be very large.
Closes-Bug: #1746294
Change-Id: I1c34964a74123b3d94ccae89d7cac0426b57b9b6
This takes most of the release note and adds it to the user
flavor docs which is more discoverable for an end user.
Change-Id: Ia83af4dfcc0c040679b0d0cd5282830fca27bd63
The ServiceLauncher and ProcessLauncher in oslo.service will,
by default, log config options at DEBUG level at the start
of a service, which is what would happen when starting nova-api
using eventlet.
Running nova-api under wsgi has been supported since Pike, but
the wsgi app code doesn't log the debug options like oslo.service
would, so this adds that back in.
The placement-api wsgi app code would log the options but based on
whether or not debug logging is enabled, which is different from how
it works in oslo.service, so the config option that is checked is
changed in this patch, and a release note is added for that subtle
behavior change.
Closes-Bug: #1732000
Change-Id: I680fd9761a049cac619b7793fa5c60e6daf4fa47
Report client's set_aggregates_for_provider and set_traits_for_provider
methods declare in their docstring that they accept an iterable for the
aggregates/traits parameter. However, passing in a set results in a
JSON serialization error. We could solve this by changing the docstring
(accept only lists). Or, as is done here, by tolerating other kinds of
iterables, converting them to lists.
Change-Id: I749ffbd9a55ee71d5dbd266ef6faa4be4a1d395b
blueprint: nested-resource-providers
Eric Fried