Add a combination of commands to allow users to show existing stashed
connection_info for a volume attachment and update volume attachments
with fresh connection_info from Cinder by recreating the attachments.
Unfortunately we don't have an easy way to access host connector
information remotely (i.e. over the RPC API), meaning we need to also
provide a command to get the compute specific connector information
which must be run on the compute node that the instance is located on.
Blueprint: nova-manage-refresh-connection-info
Co-authored-by: Stephen Finucane <stephenfin@redhat.com>
Change-Id: I2e3a77428f5f6113c10cc316f94bbec83f0f46c1
This looks more complicated than it is, but it's really quite simple.
Essentially we have to deal with two possible configurations:
- For existing deployments, the DB sync operation should apply any
outstanding sqlalchemy-migrate-based migrations, dummy apply the
initial alembic migration, and then apply any additional alembic-based
migrations requested (or any available, if no version is specified).
- For new deployments, the DB sync operation should apply the initial
alembic migration and any additional alembic-based migrations
requested (or any available, if no version is specified). No
sqlalchemy-migrate-based migrations will ever be applied.
While we continue to allow users to request a specific database
migration version to upgrade to, we *do not* allow them to request a
sqlalchemy-migrate-based migration version. There's no good reason to do
this - the deployment won't run with an out-of-date DB schema (something
that's also true of the alembic migration, fwiw) - and we want to get
people off of sqlalchemy-migrate as fast as possible. A change in a
future release can remove the sqlalchemy-migrate-based migrations once
we're sure that they'll have upgraded to a release including all of the
sqlalchemy-migrated-based migrations (so Wallaby).
Tests are modified to validate the sanity of these operations. They're
mostly trivial changes, but we do need to do some funky things to ensure
that (a) we don't use logger configuration from 'alembic.ini' that will
mess with our existing logger configuration and (b) we re-use connection
objects as necessary to allow us to run tests against in-memory
databases, where a different connection would actually mean a different
database. We also can't rely on 'WalkVersionsMixin' from oslo.db since
that only supports sqlalchemy-migrate [1]. We instead must re-invent the
wheel here somewhat.
[1] https://github.com/openstack/oslo.db/blob/10.0.0/oslo_db/sqlalchemy/test_migrations.py#L42-L44
Change-Id: I850af601f81bd5d2ecc029682ae10d3a07c936ce
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Nested allocations are only partially supported in nova-manage placement
heal_allocations CLI. This patch documents the missing support and
blocks healing instances with VGPU or Cyborg device profile request in
the embedded flavor. Blocking is needed as if --forced is used with such
instances then the tool could recreate an allocation ignoring some of
these resources.
Change-Id: I89ac90d2ea8bc268940869dbbc90352bfad5c0de
Related-Bug: bug/1939020
The task_log table contains instance usage audit records if
nova-compute has been configured with [DEFAULT]instance_usage_audit =
True. This will be the case if OpenStack Telemetry is being used in the
deployment, as the option causes nova to generate audit information
that Telemetry then retrieves from the server usage audit log API [1].
Historically, there has been no way to delete task_log table records
other than manual database modification. Because of this, task_log
records could pile up over time and operators are forced to perform
manual steps to periodically truncate the table.
This adds a --task-log option to the 'nova-manage db
archive_deleted_rows' CLI to also archive task_log records while
archiving the database. --task-log works in conjunction with --before
if operators desire archving only records that are older than <date>.
The 'updated_at' field is used by --task-log --before <date> to
determine the age of a task_log record for archival.
Closes-Bug: #1877189
[1] https://docs.openstack.org/api-ref/compute/#server-usage-audit-log-os-instance-usage-audit-log
Change-Id: Ibed67854a693c930effd4dba7aca6cd03b65bd92
I don't actually grok what this does that 'oslopolicy-checker' couldn't
do, so perhaps we can deprecate this in the future. For now though,
simply document the thing. While we're here, we make some additional
related changes:
- Remove references to the 'policy.yaml' file for services that don't
use policy (i.e. everything except the API services and, due to a bug,
the nova-compute service).
- Update remaining references to the 'policy.yaml' file to include the
'policy.d/' directory
- Update the help text for the '--api-name' and '--target' options of
the 'nova-policy policy check' command to correct tense and better
explain their purpose.
Also, yes, 'nova-policy policy check' is dumb. Don't blame me :)
Change-Id: I913b0de9ec40a615da7bf9981852edef4a88fecb
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Related-bug: #1675486
Most of these share the same collection of oslo.config and oslo.log
options so it makes sense to group them together. The only exception is
nova-rootwrap, which is a wrapper around the 'oslo_rootwrap.cmd.main'
module, which curiously does not use argparse and doesn't have any
options.
Change-Id: I393ff162be58700956fbab29ff6b9ba3cf5860a6
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
We have them. Let's use them. The resulting man pages aren't perfect,
but they're *much* better.
Change-Id: I84d54a246fecbd2f7d2950d6c6044f7cd1b8e9df
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
This is step one in improving the usability of these docs. The current
style makes it impossible to link to individual commands from the built
docs. There is a better way. Use headers along with code blocks to show
the actual command. This was mostly generated from a find-replace along
with some follow-up manual fixes.
Change-Id: Icd25006f31c8e34fe33d79779e0577dc78f96a24
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
This change introduces a new nova-status check to ensure a machine type
has been recorded for each instance within an environment.
nova-status will fail with a warning when instances are found, directing
the operator to use the previously added nova-manage list_unset and
update commands to set a machine type for these instances. The logic for
this check comes entirely from the list_unset command.
It is noted in the warning output that this can be ignored if no libvirt
or HyperV based computes are present in the environment as
hw_machine_type is only used by these two virt drivers at present.
blueprint: libvirt-default-machine-type
Change-Id: Ic3ae48c57e61c4e45883fbae1328a448be025953
This change adds a libvirt command to list all instance UUIDs with
hw_machine_type unset in their image metadata. This will be useful to
operators attempting to change the [libvirt]hw_machine_type default in
the future as it allows them to confirm if it is safe to change the
configurable without impacting existing instances.
blueprint: libvirt-default-machine-type
Change-Id: I39909ace97f62e87f326d4d822d4e4c391445765
This change adds a second update command to the libvirt group
within nova-manage. This command will set or update the machine type of
the instance when the following criteria are met:
* The instance must have a ``vm_state`` of ``STOPPED``, ``SHELVED`` or
``SHELVED_OFFLOADED``.
* The machine type is supported. The supported list includes alias and
versioned types of ``pc``, ``pc-i440fx``, ``pc-q35``, ``q35``, ``virt``
or ``s390-ccw-virtio``.
* The update will not move the instance between underlying machine types.
For example, ``pc`` to ``q35``.
* The update will not move the instance between an alias and versioned
machine type or vice versa. For example, ``pc`` to ``pc-1.2.3`` or
``pc-1.2.3`` to ``pc``.
A --force flag is provided to skip the above checks but caution
should be taken as this could easily lead to the underlying ABI of the
instance changing when moving between machine types.
blueprint: libvirt-default-machine-type
Change-Id: I6b80021a2f90d3379c821dc8f02a72f350169eb3
This change introduces the first machine_type command to nova-manage to
fetch and display the current machine type if set in the system metadata
of the instance.
blueprint: libvirt-default-machine-type
Change-Id: Idc035671892e4668141a93763f8f2bed7a630812
This command was helpful to assist users FFUing past the Pike release,
however, it's no longer helpful and should be removed now. Do just that.
Change-Id: Ib42f65dbcf61ead571e9107e7ffbba2b29f48d64
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Change I2aae01ed235f1257b0b3ddc6aee4efc7be38eb6e indicated that this
command was no longer necessary and could be removed. In hindsight, it's
been unnecessary since Liberty, which introduced a blocking migration
requiring this script be run, and it could have been deleted years ago.
No time like the present though.
Change-Id: I532c7918a8e2c887f29d2f0e1e33b80f2b3a7507
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Report a warning during upgrade checks if there are computes older than
the previous major nova release in the system.
So if code is upgraded to Wallaby and the upgrade check was run before
the restart of the services with W code then the check warns for Ussuri
computes in the system.
Change-Id: I873b0c1e6e695ae88241bbf75ac9f80ecc6f5664
policy file default and JSON format 'policy.json' is now
deprecated. Let's replace all the ref and test start using the
policy.yaml.
Change-Id: I78a273576702fb95d831bd9b801b5774fb9fd19e
Default value of 'CONF.oslo_policy.policy_file' config option
has been changed from 'policy.json' to 'policy.yaml'. If new default
file 'policy.yaml' does not exist but old default 'policy.json' exist
then fallback to use old default file.
An upgrade checks is added to check the policy_file format and
fail upgrade checks if it is JSON formatted.
Added a warning in policy doc about JSON formatted file is deprecated,
also removed all the reference to policy.json file in doc as well as
in tests.
Related Blueprint: policy-json-to-yaml
Closes-Bug: #1875418
Change-Id: Ic4d3b998bb9701cb1e3ef12d9bb6f4d91cc19c18
These do not render correctly when generating man pages and likely exist
from a time when the pages were built with rst2man (i.e. docutils)
instead of Sphinx. They're not necessary when using Sphinx since that
information is provided via the 'man_pages' config option in 'conf.py',
which are updated here to reflect reality.
Change-Id: I133e7231112cc9025e57a29d43bfa7002ca775e7
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
There are cases where policy file is re-generated freshly
and end up having the new defaults only but expectation is that
old deprecated rule keep working.
If a rule is present in policy file then, that has priority over
its defaults so either rules should not be present in policy file
or users need to update their token to match the overridden rule
permission.
This issue was always present when any policy defaults were changed
with old defaults being supported as deprecated. This is we have
changed all the policy for new defaults so it came up as broken case.
Adding nova-status upgrade check also to detect such policy file.
Related-Bug: #1875418
Change-Id: Id9cd65877e53577bff22e408ca07bbeec4407f6e
Since I537ed74503d208957f0a97af3ab754a6750dac20 had some clean-up comments,
we can just provide a follow-up change.
Change-Id: Ie8b5147322e13ad7df966b5c3c41ef0418e4f64c
Related-Bug: #1793569
There are different situations when allocations can be orphaned.
Adding a new nova-manage command to lookup at all resource providers
and check against the related compute nodes whether they have
orphaned allocations.
Change-Id: I537ed74503d208957f0a97af3ab754a6750dac20
Closes-Bug: #1793569
Placement microversion 1.35 gives us the root_required queryparam to GET
/allocation_candidates, allowing us to filter out candidates where the
*root* provider has/lacks certain traits, independent of traits
specified in any of the individual request groups.
Use it.
And add affordance for specifying such traits to the RequestSpec.
Which allows us to fix up the couple of request filters that were
hacking traits into the RequestSpec.flavor.
Change-Id: I44f02044ce178e84c23d178e5a23a3aa1208e502
This legacy service is no longer used and was deprecated during the
Stein cycle [1]. It's time to say adios and remove them in their
entirety. This is pretty straightforward, with the sole exception of
schema for the 'remote-consoles' API, which has to continue supporting
requests for type 'xvpvnc' even if we can't fulfil those requests now.
[1] https://review.opendev.org/#/c/610076/
Part of blueprint remove-xvpvncproxy
Depends-On: https://review.opendev.org/695853
Change-Id: I2f7f2379d0cd54e4d0a91008ddb44858cfc5a4cf
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
If a nova-manage command is executed without the -h option
or a subcommand the user gets an ugly traceback. This is
easily recreated:
$ tox -e venv -- nova-manage db
Make the action argument required, so we get a helpful error message
instead.
$ nova-manage db
usage: nova-manage db [-h]
{archive_deleted_rows,ironic_flavor_migration,
null_instance_uuid_scan,online_data_migrations,
purge,sync,version}
...
nova-manage db: error: the following arguments are required: action
Note that unit tests appear to be impossible for this, since doing so
attempts to initialize an oslo.config 'CONF' singleton and this is
something we've already done in 'nova.test' and can't do again.
Change-Id: I24d03eed3aa3b882c49916938f4c25d76fd4e831
Closes-Bug: #1837199
Co-Authored-By: Stephen Finucane <stephenfin@redhat.com>
This has come up a few times via support questions from operators
that have a nova cell database out of sync with the placement
database resulting in a mismatch in compute nodes to provider
uuids and they just want to wipe the placement database and rebuild
it from the current data in nova. This provides a document with the
high level steps to do that.
Change-Id: Ie4fed22615f60e132a887fe541771c447fae1082
This commit cuts us over to using placement microversion 1.34 for GET
/allocation_candidates, thereby supporting string request group suffixes
(added in 1.33) when specified in flavor extra_specs.
The mappings (added in 1.34) are not used in code yet, but a future
patch will tie the group suffixes to the RequestGroup.requester_id so
that it can be correlated after GET /a_c. This will allow us to get rid
of map_requested_resources_to_providers, which was a hack to bridge the
gap until we had mappings from placement.
Change-Id: I52499ff6639c1a5815a8557b22dd33106dcc386b
Get excited, people. It's finally dying, for real. There is a lot more
doc work needed here, but this is a start. No need for a release note
modification since we've already said that nova-network has been
removed, so there's no point in saying that the service itself has been
removed since that's implicit.
Change-Id: I18d73212f9d98bc75974a024cf6fd872fdfb1ca4
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
There are actually a few things here that rely on a running
nova-dhcpbridge instances, but since it's not possible to start
nova-network now, that shouldn't matter.
Change-Id: I63447baeaac0be3fb7f919bfe588da50133c74d7
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
This legacy service was only compatible with the XenServer driver and
has effectively been replaced by the noVNC console proxy service. Remove
the service. The API that provided remote access to this service,
'os-consoles', was removed in a previous change. Note that
'os-remote-consoles' is unrelated and therefore is not removed, though
it will now reject requests for XVP VNC consoles.
This was previously discussed and agreed on openstack-dev [1] and
openstack-discuss [1].
Part of blueprint remove-xvpvncproxy
[1] http://lists.openstack.org/pipermail/openstack-dev/2018-October/135413.html
[2] http://lists.openstack.org/pipermail/openstack-discuss/2019-April/005369.html
Change-Id: Ib1ff32f04b16af7981471f67c8e0bf04e6ecb6be
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
While we do not have an automated fix for bug 1849479 this provides
a troubleshooting document for working around that issue where
allocations from a server that was evacuated from a down host need
to be cleaned up manually in order to delete the resource provider
and associated compute node/service.
In general this is also a useful guide for linking up the various
resources and terms in nova and how they are reflected in placement
with the relevant commands which is probably something we should
do more of in our docs.
Change-Id: I120e1ddd7946a371888bfc890b5979f2e19288cd
Related-Bug: #1829479
A blocker migration was added in Train [1] to force
deployments to make sure they have completed the
services.uuid online migration (added in Pike). Now
that we're in Ussuri we can drop that online data
migration code.
Note that InstanceListWithServicesTestCase is removed
because the scenario is now invalid with the blocker
DB migration.
[1] I8927b8a4513dab242d34953d13dd2cc95393dc80
Change-Id: If77702f0c3212f904443f627037782f9ad7b3b55
