The 'bochs' display device is a recommended[1] safe option for UEFI
guests. This is supported in libvirt from version 5.6.0; Nova's current
MIN_LIBVIRT_VERSION (6.0.0) satisfies this requirement.
Partially quoting the "bochs display device" section from a post written
by a QEMU graphics maintainer[1]:
[...] Main advantage over standard VGA is that this device is alot
simpler. The code size and complexity needed to emulate this device
is an order of magnitude smaller, resulting in a reduced attack
surface. Another nice feature is that you can place this device in a
PCI Express slot.
For UEFI guests it is safe to use the bochs display device instead
of the standard VGA device. The firmware will setup a linear
framebuffer as GOP anyway and never use any legacy VGA features.
For BIOS guests this device might be useable as well, depending on
whenever they depend on direct VGA hardware access or not. There is
a vgabios which supports text rendering on a linear framebuffer, so
software which uses the vgabios services for text output will
continue to work. Linux bootloaders typically fall into this
category. The linux text mode console (vgacon) uses direct hardware
access and does not work. The framebuffer console (fbcon running on
vesafb or bochs-drm) works.
[1] https://www.kraxel.org/blog/2019/09/display-devices-in-qemu/
Implements: blueprint add-bochs-display-device
Change-Id: Id194028f5d2cbaac1c5e699b71fd9751f87f5da5
Signed-off-by: Kashyap Chamarthy <kchamart@redhat.com>
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
The interface attach and detach logic is now fully adapted to the new
extended resource request format, and supports more than one request
group in a single port.
blueprint: qos-minimum-guaranteed-packet-rate
Change-Id: I73e6acf5adfffa9203efa3374671ec18f4ea79eb
Nova re-generates the resource request of an instance for each server
move operation (migrate, resize, evacuate, live-migrate, unshelve) to
find (or validate) a target host for the instance move. This patch
extends the this logic to support the extended resource request from
neutron.
As the changes in the neutron interface code is called from nova-compute
service during the port binding the compute service version is bumped.
And a check is added to the compute-api to reject the move operations
with ports having extended resource request if there are old computes
in the cluster.
blueprint: qos-minimum-guaranteed-packet-rate
Change-Id: Ibcf703e254e720b9a6de17527325758676628d48
This adds the final missing pieces to support creating servers with
ports having extended resource request. As the changes in the neutron
interface code is called from nova-compute service during the port
binding the compute service version is bumped. And a check is added to
the compute-api to reject such server create requests if there are old
computes in the cluster.
Note that some of the negative and SRIOV related interface attach
tests are also started to pass as they are not dependent on any of the
interface attach specific implementation. Still interface attach is
broken here as the failing of the positive tests show.
blueprint: qos-minimum-guaranteed-packet-rate
Change-Id: I9060cc9cb9e0d5de641ade78c5fd7e1cc77ade46
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
To prepare for the unlikely event that Neutron merges and an operator
enables the port-resource-request-groups neutron API extension before
nova adds support for it, this patch rejects server creation if such
extension is enabled in Neutron. Enabling that extension has zero
benefits without nova support hence the harsh but simple rejection.
A subsequent patch will reject server lifecycle operations in a more
sophisticated way and as soon as we support some operations, like
boot, the deployer might rightfully choose to enable the Neutron
extension.
Change-Id: I2c55d9da13a570efbc1c862116cea31aaa6aa02e
blueprint: qos-minimum-guaranteed-packet-rate
Alembic does lots of new things. Provide docs for how to use this. We
also improve upgrade docs slightly, removing references to ancient
reviews that are no longer really helpful as well as calling out our N
-> N+1 constraint.
Change-Id: I3760b82ce3bd71aa0a760d7137d69dfa3f29dc1d
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
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>
The two remaining modules, 'api_models' and 'api_migrations', are
moved to the new 'nova.db.api' module.
Change-Id: I138670fe36b07546db5518f78c657197780c5040
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
As a prerequisite for blueprint generic-mdevs we need to rename the
existing enabled_vgpu_types options and dynamically generated groups
into enabled_mdev_types.
There is no upgrade impact for existing users, as the original
options are still accepted.
NOTE(sbauza): As we have a lot of methods and objects named gpu-ish
let's just change what we need here and provide followups for
fixing internal tech debt later.
Change-Id: Idba094f6366a24965804b88da0bc1b9754549c99
Partially-Implements: blueprint generic-mdevs
Correct a variety of gaps and other issues seen while improving the
flavor docs.
Change-Id: I8d68016cecb0269a5f9af88b0a08578f85403e23
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Replace references to novaclient with OSC in the boot from volume guide.
This is essentially a revert of commit aa3964118, which was a revert of
an earlier attempt at doing this that fell down because it didn't
reflect the changes in CLI parameters between the different tools.
Change-Id: Ic99440dd618243517f64506e3da88885fc2c44c9
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
We place these in a 'legacy_migrations' directory, as we will soon be
adding alembic-based migrations in a 'migration' directory.
Change-Id: Ib927e4c48f59a467a913875111ffbf64ffe0de90
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
There are no longer any custom filters. We don't need the abstract base
class. Merge the code in and give it a more useful 'SchedulerDriver'
name.
Change-Id: Id08dafa72d617ca85e66d50b3c91045e0e8723d0
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
The link of `TLS everywhere` should be 'https://docs.openstack.org/
project-deploy-guide/tripleo-docs/latest/features/tls-everywhere.html'.
Closes-Bug: #1933062
Change-Id: I468b82edeb899b0a780f8b545ad23ee0428a93ea
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
Nova does not support renaming a node once it has been deployed.
Previously, this was not mentioned anywhere in our docs. This patches
adds a warning to that effect to the installation guide.
Change-Id: I0f34c89855069119974d75d31833b974ba705306
Nova does not support all the scope provided by
keystone. It is better to mention the supported
scope and default roles.
Also adding a table to map the legacy rules with new
rules.
Change-Id: If7f025b3eaeda2df0cb1efd567b8fc60e274d09c
This change deprecates the AZ filters which is no longer required.
This also enable the use of placement for AZ enforcement by default and
deprecates the config option for removal.
Change-Id: I92b0386432444fc8bdf852de4bdb6cebb370a8ca
We now have good documentation on the PCI NUMA affinity policies
(thanks, artom!) so we can close out this TODO. Hurrah!
Change-Id: I4e6402bd192ea0d2efb26b52a7ceb65d924ec928
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
