A todo in the contributor/placement.rst slipped through the review
cracks and meant a bad link to 'link to spec once it merges' is in the
docs. This fixes it with the correct link to the spec.
Change-Id: I13daf9576dcb1229409826b4c4eac28c8bb1e23f
Blueprint add-kvm-hidden-feature added the capability of hiding the kvm
signature from guests. However, it was implemented only through an image
property.
A major reason for this feature is to allow passed-through Nvidia GPUs
to work correctly. GPU pci-passthrough is specified on the flavor's
extra_specs, without requiring an image with special properties.
Therefore, hiding the KVM signature should also be specifiable through
the flavor's extra_specs, in order to not require a special image for
this use case.
If the new flavor extra_spec is present and set to 'true', the libvirt
driver will produce an additional element to hide kvm's signature on
the vm, in the same way as with the image property
`img_hide_hypervisor_id`.
Implements: blueprint hide-hypervisor-id-flavor-extra-spec
Closes-Bug: 1757424
Change-Id: I41c5913b4148629b448ea5fb43b7597dc067dc22
xenapi is going to support pool-based multi-hosts OpenStack
environments, this patch is used to remove dependency to the
old aggregate-based-pools and add support to xenapi pool.
Also include unit test changes.
Updated configuring migrations document:
https://docs.openstack.org/nova/latest/admin/configuring-
migrations.html#configuring-migrations-xenserver-shared-storage
Other related documents will be updated in another patch.
Implements: blueprint live-migration-in-xapi-pool
Change-Id: I2c492c46e85c1df96aa7fdc12cdee0b1c7ba775e
Accept forbidden traits in the processing of extra_specs, with the
format of:
trait:CUSTOM_MAGIC=forbidden
This will be transformed into required=!CUSTOM_MAGIC when the traits
are assembled into a request to GET /allocation_candidates.
Implements blueprint forbidden-traits-in-nova
Change-Id: I31e609aef47d2fea03f279e4bfdd30f072d062b4
Since BFV instances don't have a specific image attached to them, the
filter will consider them as not having a specific image, hence not
isolated. Correcting the doc.
Change-Id: Ib235fca1365ee7a38b94600960ee3947f448c4a9
This adds information to the "notification_format" config
option help and notifications docs on how to disable notifications.
While updating the config option help text, a stale reference
to Pike is removed.
Change-Id: I736025a0a88fc969831558805687b642da8cd365
Closes-Bug: #1761405
The API-sig has a guideline[1] for including error codes in error
responses to help distinguish errors with the same status code
from one another. This change provides a simplest-thing-that-could-
possibly-work solution to make that go.
This solution comes about after a few different constraints and attempts:
* We would prefer to go on using the existing webob.exc exceptions, not
make subclasses.
* We already have a special wrapper around our wsgi apps to deal with
setting the json_error_formatter.
* Though webob allows custom Request and Response objects, it uses the
default Response object as the parent of the HTTP exceptions.
* The Response object accepts kwargs, but only if they can be associated
with known attributes on the class. Since we can't subclass...
* The json_error_formatter method is not passed the raw exception, but
it does get the current WSGI environ
* The webob.exc classes take a 'comment' kwarg that is not used, but
is also not passed to the json_error_formatter.
Therefore, when we raise an exception, we can set 'comment' to a code
and then assign that comment to a well known field in the environ and if
that environ is set in json_error_formatter, we can set 'code' in the
output.
This is done in a new microversion, 1.23. Every response gets a default
code 'placement.undefined_code' from 1.23 on. Future development will
add specific codes where required. This change adds a stub code for
inventory in use when doing a PUT to .../inventories but the name
may need improvement.
[1] http://specs.openstack.org/openstack/api-wg/guidelines/errors.html
Implements blueprint placement-api-error-handling
Change-Id: I9a833aa35d474caa35e640bbad6c436a3b16ac5e
currently we have following output:
$ curl http://169.254.169.254/openstack
2012-08-10
2013-04-04
2013-10-17
2015-10-15
2016-06-30
2016-10-06
2017-02-22
latest
Change-Id: I6b4aed63d5c981abc9374baf929f05b26760e645
Change Ib984c30543acb3ca9cb95fb53d44d9ded0f5a5c8, which was added
in Newton when cells v2 was optional, added some transitional code
to the API for looking up an instance, which didn't rely on instance
mappings in a cell to find the instance if the minimum nova-osapi_compute
service version was from before Ocata.
People have reported this being a source of confusion when upgrading
from before Ocata, when cells v2 wasn't required, to Ocata+ where cells
v2 along with the mapping setup is required. That's because they might
have older nova-osapi_compute service version records in their 'nova'
(cell) database which makes the API think the code is older than it
actually is, and results in an InstanceNotFound error.
This change does two things:
1. Adds a warning to the compute API code in this scenario to serve
as a breadcrumb if a deployment hits this issue.
2. A nova-status check to look for minimum nova-osapi_compute service
versions across all cells and report the issue as a warning. It's
not an upgrade failure since we don't know how the nova-api service
is configured, but leave that investigation up to the deployer.
This is also written in such a way that we should be able to backport
this through to stable/ocata.
Change-Id: Ie2bc4616439352850cf29a9de7d33a06c8f7c2b8
Closes-Bug: #1759316
It is not uncommon to triage bugs on a weekly basis where the
[neutron] auth credentials are not configured in nova.conf, which
generally leads to a 500 response in the compute API because of
the auth error.
With respect to neutron, the compute install guides really only
say to set use_neutron=True, but don't mention that configuring
the [neutron] section for auth is required. The networking service
install guide does, so it's a bit confusing why people make this
mistake in the first place, but as a reminder, this change adds
links from the compute install guide to the relevant sections
in the networking service install guides.
Change-Id: Id17457bd2770fcbebd6231919ba4002e75410089
Closes-Bug: #1761487
Everyone seems to agree that the only sane ordering of these operations
is "api first, cell after." However, grenade and our own documentation
shows the api database as coming after the main one. I believe this
was added to grenade in a sort of append operation, and thus after the
main database. This was done back when usage of the API database was
still optional (for upgrades) and thus the ordering didn't matter much.
Since the process has been correct (api first) in devstack for a long
time, and since grenade runs after devstack, we haven't had any issues.
A recent change to add something to a core data structure column format
highlighted the out-of-order-ness of this.
I also believe the docs got the same append behavior when adding the
command to the list, and/or it may have been copied from grenade, which
is our in-code manifestation of the upgrade steps.
Change-Id: I19f263ed314a8b01bbb07337467392cc1c146b66
Related-Bug: #1761775
In Pike we started requiring that ironic instances have their
embedded flavor migrated to track the ironic node custom
resource class. This can be done either via the normal running
of the nova-compute service and ironic driver or via the
'nova-manage db ironic_flavor_migration' command.
This change adds a nova-status check to see if there are any
unmigrated ironic instances across all non-cell0 cells, and
is based mostly on the same logic within the nova-manage command
except it's multi-cell aware and doesn't use the objects.
Change-Id: Ifd22325e849db2353b1b1eedfe998e3d6a79591c
Through these new options, users can enable or disable a cell
through the CLI.
Related to blueprint cell-disable
Change-Id: I761f2e2b1f1cc2c605f7da504a8c8647d6d6a45e
this document is out of date since a set of changes made such as
43f91a87cb39f6159bde8be8d02aa7
Put those 'to be fixed in queens' make people think it should
be already been fixed due to queen release, so remove them in order
to avoid confusion and we can continue to enhance this doc.
TrivialFix
Change-Id: I12dd385f4e1f159bdb9a78a629d4095889397c09
A recent IRC conversation [1] discussed that there are generally no tests
for the placement handler code (the wsgi methods that respond to each
URI and HTTP method). This change adds a paragraph to point out that
this is mostly intentional and that when they get complex it would
be a good idea to extract a method.
[1] http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2018-03-28.log.html#t2018-03-28T13:00:40
Change-Id: I09774c123068e42e6a828fc37455dc5d374486b9
This adds the ability to hotplug network interfaces for the powervm
virt driver.
Blueprint: powervm-network-hotplug
Change-Id: I78b94c9731c35e3291d46b9bf9f5554e21c2429e
This uses the member_of query parameter to placement to ensure that the
candidates returned are within the appropriate aggregate(s) if so
specified.
Related to blueprint placement-req-filter
Change-Id: If8ac06039ac9d647efdc088fbe944938e205e941
It has long been *recommended* that the placement service be upgraded
before nova services, but scenarios where it isn't have never really
been explored or tested. Following (yet another) discussion on the
topic [1] it was decided that we are best served by *requiring* that
placement be updated first. This simplifies our test/support matrix,
and the code we write to consume placement. It also makes the operator
experience cleaner by giving them a clear and unambiguous script to
follow.
This change set rewords the upgrade document accordingly.
[1] http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2018-03-26.log.html#t2018-03-26T17:35:11
Change-Id: I97215e94efdd8c05045872fb9ba7d2089dc6efb8
This patch adds the new column disabled to the list of columns to be
displayed by the list_cells command.
Related to blueprint cell-disable
Change-Id: I96a6d5e59d33c65314fc187c0286ce3408d30bdc
This patch removes the unnecessary maintenance of a date and version
from the CLI documentation.
NOTE: Cinder team also did the same removal with
the commit Idf78bbed44f942bb6976ccf4da67c748d9283ed9
Change-Id: I0a9dd49e68f2d47c58a46b107c77975e7b2aeaf7
Chris Dent