This addresses comments from code review to add handling of PCPU during
the migration/copy of limits from the Nova database to Keystone. In
legacy quotas, there is no settable quota limit for PCPU, so the limit
for VCPU is used for PCPU. With unified limits, PCPU will have its own
quota limit, so for the automated migration command, we will simply
create a dedicated limit for PCPU that is the same value as the limit
for VCPU.
On the docs side, this adds more detail about the token authorization
settings needed to use the nova-manage limits migrate_to_unified_limits
CLI command and documents more OSC limit commands like show and delete.
Related to blueprint unified-limits-nova-tool-and-docs
Change-Id: Ifdb1691d7b25d28216d26479418ea323476fee1a
When people transition from three ironic nova-compute processes down
to one process, we need a way to move the ironic nodes, and any
associcated instances, between nova-compute processes.
For saftey, a nova-compute process must first be forced_down via
the API, similar to when using evacaute, before moving the associated
ironic nodes to another nova-compute process. The destination
nova-compute process should ideally not be running, but not forced
down.
blueprint ironic-shards
Change-Id: I7ef25e27bf8c47f994e28c59858cf3df30975b05
This command aims to help migrate to unified limits quotas by reading
legacy quota limits from the Nova database and calling the Keystone API
to create corresponding unified limits.
Related to blueprint unified-limits-nova-tool-and-docs
Change-Id: I5536010ea1212918e61b3f4f22c2077fadc5ebfe
This adds some admin guide documentation about the stable compute_id
file. It covers upgrade, greenfield generation, and greenfield
pre-provisioning by deployment tools.
Related to blueprint stable-compute-uuid
Change-Id: I078b3f9e1919f2008628dc7b889e8696f1f6159a
nova-manage doc page [1] mentioned usage of `nova-manage db archive`
command, which doesn't exist.
This change updates the doc page with the correct command
`nova-manage db archive_deleted_rows`.
[1] https://docs.openstack.org/nova/latest/cli/nova-manage.html
Closes-Bug: #1981088
Change-Id: Ibcbccf87ec70e9edea61c99d4d3bcf610cc1df64
We have droped the system scope from Nova policy
and keeping the legacy admin behaviour same. This
commit adds the releasenotes and update the policy
configuration documentation accordingly.
Also, remove the upgrade check for policy which was
added for the system scope configuration protection.
Change-Id: I127cc4da689a82dbde07059de90c451eb09ea4cf
This a follow up for change Ic8783053778cf4614742186e94059d5675121db1
and corrects the 'image_property set --property' arg format in the
hw_machine_type doc. Newline formats in the nova-manage CLI doc is
cleaned up to be consistent throughout and unnecessary () is removed
from the ImagePropertyCommands class.
Related to blueprint libvirt-device-bus-model-update
Change-Id: I5b67e9ae5125f6dad68cae7ac0601ac5b02e74b3
This adds an image property show and image property set command to
nova-manage to allow users to update image properties stored for an
instance in system metadata without having to rebuild the instance.
This is intended to ease migration to new machine types, as updating
the machine type could potentially invalidate the existing image
properties of an instance.
Co-Authored-By: melanie witt <melwittt@gmail.com>
Blueprint: libvirt-device-bus-model-update
Change-Id: Ic8783053778cf4614742186e94059d5675121db1
The nova-manage placement heal_allocations CLI is capable of healing
missing placement allocations due to port resource requests. To support
the new extended port resource request this code needs to be adapted
too.
When the heal_allocation command got the port resource request
support in train, the only way to figure out the missing allocations was
to dig into the placement RP tree directly. Since then nova gained
support for interface attach with such ports and to support that
placement gained support for in_tree filtering in allocation candidate
queries. So now the healing logic can be generalized to following:
For a given instance
1) Find the ports that has resource request but no allocation key in the
binding profile. These are the ports we need to heal
2) Gather the RequestGroups from the these ports and run an
allocation_candidates query restricted to the current compute of the
instance with in_tree filtering.
3) Extend the existing instance allocation with a returned allocation
candidate and update the instance allocation in placement.
4) Update the binding profile of these ports in neutron
The main change compared to the existing implementation is in step 2)
the rest mostly the same.
Note that support for old resource request format is kept alongside of
the new resource request format until Neutron makes the new format
mandatory.
blueprint: qos-minimum-guaranteed-packet-rate
Change-Id: I58869d2a5a4ed988fc786a6f1824be441dd48484
The 'nova-manage placement audit' tool has functionality that can
delete orphaned allocations in placement. Add a section for it in the
doc for troubleshooting orphaned allocations.
Change-Id: I697de57cf7eb43c0993af2b1f5b3f5c4395ef097
Currently, when 'nova-manage db archive_deleted_rows' is run with
the --until-complete option, the process will archive rows in batches
in a tight loop, which can cause problems in busy environments where
the aggressive archiving interferes with other requests trying to write
to the database.
This adds an option for users to specify an amount of time in seconds
to sleep between batches of rows while archiving with --until-complete,
allowing the process to be throttled.
Closes-Bug: #1912579
Change-Id: I638b2fa78b81919373e607458e6f68a7983a79aa
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
To implement the usage of same_subtree query parameter in the
allocation candidate request first the minimum requires placement
microversion needs to be bumped from 1.35 to 1.36. This patch makes such
bump and update the related nova upgrade check. Later patches will
modify the query generation to include the same_subtree param to the
request.
Change-Id: I5bfec9b9ec49e60c454d71f6fc645038504ef9ef
blueprint: qos-minimum-guaranteed-packet-rate
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>
