We're going to start ripping out cells v1. First step is removing the
tests for this soon-to-be-removed feature.
Part of blueprint remove-cells-v1
Change-Id: I2031bf2cc914d134e5ed61156d2cfc621f006e0b
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
Seeing as these were missed for Rocky, we really ought to get them in
for Stein.
Change-Id: I29401773a0686e7be5d7d1cbb5ec82ffbb16fb4a
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
The compute node has left the attachment information after the
encryption fails. This patch fixes this by ensuring the volume is
disconnected when an exception occurs.
Change-Id: I9d652f182d83a2557ff6ed0b21c69a735c3f9840
Closes-Bug: #1812945
When running 'nova-manage simple_cell_setup...' if there are not hosts
to map, but there remaining instances to map, an '..., exiting' message
is produced. This is misleading because "exiting" implies a return of
control to the user. That doesn't happen if there are many instances
left to inspect or map.
This change gets around that by getting rid of the exiting message
in the case where instance mapping can still happen.
Change-Id: I62b20a3676429b5cc756884275138566785b347e
Closes-Bug: #1821737
Using the new PrivsepFixture, improve test coverage of filesystem
utilities. This finishes off coverage for this file.
Change-Id: I4af57ced168cf285cd3872d20dc2a369b3ac2e14
Using the new PrivsepFixture, improve test coverage of the path
utilities. I've tweaked how writefile() works while doing this
because I think its previous behaviour was confusing on reflection.
Change-Id: I875402581d9593474923ee8458caec3dd4423ebd
As noted in [1]:
We always import privsep modules like this:
import nova.privsep.libvirt
Not like this:
from nova.privsep import libvirt
This is because it makes it obvious at the caller that a priviledged
operation is occuring:
nova.privsep.libvirt.destroy_root_filesystem()
Not just:
libvirt.destroy_root_filesystem()
This is especially true when the imported module is called "libvirt",
which is a very common term in the codebase and super hard to grep
for specific uses of.
This commit introduces hacking rule N362 to enforce the above.
Change-Id: I9b6aefa015acbf28e49a9ff1713a8bb544586579
Co-Authored-By: Eric Fried <openstack@fried.cc>
The compute_monitors configuration option is empty by
default, however, on nova-compute startup we get a warning
logged saying:
Excluding nova.compute.monitors.cpu monitor virt_driver. \
Not in the list of enabled monitors (CONF.compute_monitors).
This is unnecessary noise in the logs when nova-compute is
not configured to use monitors, so this change avoids the warning
log message in that case.
The compute_monitors configuration option help text is also
updated to (1) fix formatting and (2) remove the mention of the
numa_mem_bw monitor which never made it into nova (see
blueprint memory-bw).
Change-Id: I5bd204e0017f6f795e3cf13b34b75124ee23aa78
Closes-Bug: #1823207
Based on bug 1823104 it's clear we should have some
explicit wording in the notification reference docs
about what not to include in versioned notification
payloads, so this change attempts to start that with
the most obvious thing - don't expose access credentials
to the nova deployment.
This also adds a reminder to think about what is being
added / mirrored from internal objects and determine if
consumers really need it and if they aren't asking, opt
to not including it until requested.
Change-Id: I326aa39d963091282a5d0b70ba222abfe8ccfdac
Related-Bug: #1823104
Change I019e88fabd1d386c0d6395a7b1969315873485fd in Stein, which
is not yet officially released, exposes the unencrypted
database_connection URL and MQ transport_url to a CellMapping in
the select_destinations versioned notification CellMappingPayload.
While notifications are not meant to be consumed by end users of
the cloud but only internal services of the deployment, it still
seems like a bad idea to give the keys to the nova cell DB and MQ
to an external-to-nova service like ceilometer.
This change removes the fields from the CellMappingPayload and
bumps the major version to 2.0 to signal the change to consumers,
although I don't expect anything is consuming this yet but we should
follow standard versioning procedure anyway.
Note that notification consumers do not request a specific payload
version nor do they get a schema to perform their own backporting,
they just get what they get, so after this there should be no worry
about needing to support the 1.0 format for this payload.
Change-Id: Ib5edea32d15db01000e6730aebceaf119daf8c5c
Closes-Bug: #1823104
The description on the 'events' parameter for the
POST /os-server-external-events API did not make sense,
so this re-words it.
Change-Id: Iaec80e03a8ab0cd1b34126701bd0754953394e42
Whenever I use the os-instance-actions API I have to look at
the DB API source code to figure out the sort order of the
resulting instanceActions and each action's events, which
is desc(created_at) in both cases (and desc(id) but that should
not matter here since the id is not exposed in the API).
This change mentions the resulting sort order of those fields
in the API reference so I can stop looking at source code.
[1] https://github.com/openstack/nova/blob/e7ae6c65c/nova/db/sqlalchemy/api.py#L5149
[2] https://github.com/openstack/nova/blob/e7ae6c65c/nova/db/sqlalchemy/api.py#L5289
Change-Id: Ib5758bc21296e8b6c041198661c147b8e99d57e5
This was added in Newton:
I97b72ae3e7e8ea3d6b596870d8da3aaa689fd6b5
And was meant to migrate keypairs from the cell
(nova) DB to the API DB. Before that though, the
keypairs per instance would be migrated to the
instance_extra table in the cell DB. The migration
to instance_extra was dropped in Queens with change:
Ie83e7bd807c2c79e5cbe1337292c2d1989d4ac03
As the commit message on ^ mentions, the 345 cell
DB schema migration required that the cell DB keypairs
table was empty before you could upgrade to Ocata.
The migrate_keypairs_to_api_db routine only migrates
any keypairs to the API DB if there are entries in the
keypairs table in the cell DB, but because of that blocker
migration in Ocata that cannot be the case anymore, so
really migrate_keypairs_to_api_db is just wasting time
querying the database during the online_data_migrations
routine without it actually migrating anything, so we
should just remove it.
Change-Id: Ie56bc411880c6d1c04599cf9521e12e8b4878e1e
Closes-Bug: #1822613
As part of adding support for bandwidth based scheduling
I038867c4094d79ae4a20615ab9c9f9e38fcc2e0a introduced
automatic discovery of parent netdev names for PCIe
virtual functions.
Nova's PCI passthrough support was originally developed for
Intel QAT devices and other generic PCI devices. Later support
for Neutron based SR-IOV NIC was added.
The PCI-SIG SR-IOV specification while most often used by NIC
vendors to virtualise a NIC in hardware was designed for devices
of any PCIe class. Support for Intel's QAT device and other
accelerators like AMD's SRIOV based vGPU have therefore been
regressed by the introduction of the new parent_ifname lookup code.
This change simply catches the exception that would be raised
when pci_utils.get_ifname_by_pci_address is called on generic
VFs allowing a graceful fallback to the previous behaviour.
Change-Id: Ib3811f828246311d90b0e3ba71c162c03fb8fe5a
Closes-Bug: #1821938
Stephen Finucane