We were using `warning`, and `important` themes to mark deprecations in
various places. We have a `deprecated` role, so this change switches to
use it.
Note that I also found the following files that mentioned deprecation,
but not in a way where using this role seemed appropriate. I'm
recording them here so you know I considered them.
doc/source/admin/configuration/hypervisor-kvm.rst
doc/source/admin/configuration/schedulers.rst
doc/source/cli/index.rst
doc/source/cli/nova-rootwrap.rst
doc/source/contributor/api.rst
doc/source/contributor/code-review.rst
doc/source/contributor/policies.rst
doc/source/contributor/project-scope.rst
doc/source/reference/policy-enforcement.rst
doc/source/reference/stable-api.rst
doc/source/user/feature-classification.rst
doc/source/user/flavors.rst
doc/source/user/upgrade.rst
Change-Id: Icd7613d9886cfe0775372c817e5f3d07d8fb553d
A recent'ish change in openstack-manuals [1] noted the new support for
NUMA topologies when using the Hyper-V driver. As part of this change, a
section was added that describes the configuration steps that were
necessary on Hyper-V hosts before booting instances. However, the way
this section is integrated gives the impression that NUMA support is a
Hyper-V only feature.
Correct this by moving this configuration step to the end of the
document and instead opting to link to it from higher in the doc.
[1] https://review.openstack.org/#/c/424102/
Change-Id: Ic8d9c1b35d52a26374763b5c0e4be79875814569
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
As of Rocky, the cell databases are being used for storing console
authorizations, so the layout for running console proxies has
changed from global to a deployment to per cell.
Part of blueprint convert-consoles-to-objects
Change-Id: If5c7b081682f0cb36a678d0e21e26b7985cd8527
ExactCoreFilter, ExactDiskFilter and ExactRamFilter were deprecated
for removal in the Pike release [1] and are now being removed.
Now scheduling will use the custom resource class defined for each
baremetal node to make its selection.
[1] I843353427c90142a366ae9ca63ee4298b4f3ecd4
Change-Id: Ie25a5f6c28c20f589016791970da8d5849ec291c
This was missed in I90ee8a2081c2a0465441a8d81d161f4887b4e1fb
presumably because we no longer get warnings as errors, or
some such wickedness. Anyway, this fixes docs build using tox.
Change-Id: Ic8ec0c54a7c6502a0a4ea91d034fa9c1ae5e59d4
Closes-Bug: #1767192
Since we have a recorded overview and demo for
volume multi-attach we should link to it from our
docs.
Change-Id: I6e0e243dbb1e1203dd31e820ea12dc7aaa227b64
Change I2c492c46e85c1df96aa7fdc12cdee0b1c7ba775e removed the
need to the host aggregate up-call when doing non-block
live migration in the xenapi driver. This change adds a note
in the cells v2 layout docs saying the upcall is resolved.
Related to blueprint live-migration-in-xapi-pool
Change-Id: I7fe6ed428c77a0f719afb957d74e517f1ab9a991
xenapi is going to support pool-based multi-hosts OpenStack
environments, aggregate-based-pools support was removed in
change I2c492c46e85c1df96aa7fdc12cdee0b1c7ba775e.
This patch is used to update related OpenStack documents.
Change-Id: I9a1244fb23aea99eb246325d5655ab005dca42b4
Implements: blueprint live-migration-in-xapi-pool
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
The auth_uri option was deprecated and renamed in Queens:
I0cf11da3d395749df28077427689fdafc8a6b981
The auth_uri option is also no longer necessary, at least
for the purpose of the nova install guide, since all identity
service requests can be served through the single auth_url.
This change removes auth_uri usage and also updates the
auth_url value to match what is in the keystone install
guide:
https://docs.openstack.org/keystone/queens/install/keystone-install-ubuntu.html
Change-Id: Iff332890cbe1ba5b3876874e351b09c377d8dd5d
Closes-Bug: #1765144
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
nova provides many different types of filter, providing both resource
stacking/spreading and affinity/anti-affinity patterns. Curiously
enough, however, there is no way to configure a stack or spread policy
of CPUs. Add one.
Change-Id: I90ee8a2081c2a0465441a8d81d161f4887b4e1fb
Implements: bp vcpu-weighter
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
Zuul