Libvirt has implemented the capability to expose maximum number of
SEV guests and SEV-ES guests in 8.0.0[1][2]. This allows nova to detect
maximum number of memory encrypted guests using that feature.
The detection is not used if the [libvirt] num_memory_encrypted_guests
option is set to preserve the current behavior.
Note that current nova supports only SEV and does not support SEV-ES,
so this implementation only uses the maximum number of SEV guests.
The maximum number of SEV-ES guests will be used in case we implement
support for SEV-ES.
[1] https://gitlab.com/libvirt/libvirt/-/commit/34cb8f6fcd6a56a7bbcef2f7402def1682509e16
[2] https://gitlab.com/libvirt/libvirt/-/commit/7826148a72c97367fc6aaa76397fe92d32169723
Implements: blueprint libvirt-detect-sev-max-guests
Change-Id: I502e1713add7e6a1eb11ecce0cc2b5eb6a14527a
The URLs had the wrong order of "/latest/nova" instead of the correct
one, leading to "404 not found" errors.
Closes-Bug: 2036530
Change-Id: I083381ad2649c06be9443f5ed6a55bddafab4df8
If we are starting up and we think we are a new host (i.e. no pre-
existing service record was found for us), we expect to have no
instances on our hypervisor. If that is not the case, it is likely
that we got pointed at a new fresh database or the wrong database
(i.e. a different cell from our own). In that case, we should abort
startup to avoid creating new service, compute node, and resource
provider records.
This is a sort of follow-on additional improvement related to
work done in blueprint stable-compute-uuid.
Change-Id: Id817c51c90485119270f3b7f3c52858f42100637
We had a long blip between Xena and now where we didn't changed the libvirt
versions. Now it's time to modify the documentation for it.
Change-Id: Ida10f12d7dd950e470ba06d0f38c3dd6ac7f8876
TODO: We should also modify the supported distro versions.
Add file to the reno documentation build to show release notes for
stable/2023.2.
Use pbr instruction to increment the minor version number
automatically so that master versions are higher than the versions on
stable/2023.2.
Sem-Ver: feature
Change-Id: Ifd0b0ebbe148a323304a9e422e4c7f2bf39757f8
modifies nova-ovs-hybrid-plug job to disable cinder and swift to
ensure we test for this going forward.
Change-Id: I52046e6f7acdfb20eeba67dda59cbb5169e5d17e
Per the SQLAlchemy docs [1]:
The relationship.backref keyword should be considered legacy, and use
of relationship.back_populates with explicit relationship() constructs
should be preferred.
A number of the relationships defined here don't have foreign keys (long
live mordred?) so their conversion is slightly more difficult than would
otherwise be the case. A blog post is available to explain what's going
on [2] and might be worth a read. The learnings from that blog post do
have the benefit of allowing us to simplify some existing relationships
that had unnecessary arguments defined.
[1] https://docs.sqlalchemy.org/en/14/orm/backref.html
[2] https://that.guru/blog/sqlalchemy-relationships-without-foreign-keys/
Change-Id: I5a135b012dabdff7cf06204fc3c5438aaa0985c9
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
This change refactors prvisep util test cases to account for the
fact that oslo.log now conditionally uses an internal pipe mutex
when logging under eventlet.
This was added by Iac1b0891ae584ce4b95964e6cdc0ff2483a4e57d
which is part of oslo.log 5.3.0
As a result we need to mock all calls to oslo.log in unit tests
that are assertign if os.write is called. when the internal
pipe mutex is used oslo.log calls os.write when the mutex is
released.
Related-Bug: #1983863
Change-Id: Id313669df80f9190b79690fff25f8e3fce2a4aca
We agreed last cycle on the support envelope.
Pre-RC1, we need to add a service version in the object.
Post-RC1, depending on whether it's SLURP or not SLURP, we need to bump
the minimum version or not.
This patch only focuses on pre-RC1 stage.
Given Caracal is SLURP, we won't need any post-RC1 patch for updating the min
that will stay to be Antelope.
HTH.
Change-Id: I50deead4bbd1e383c9e4ca472a3d2724b78ee104
This change ensure we only try to clean up dangling bdms if
cinder is installed and reachable.
Closes-Bug: #2033752
Change-Id: I0ada59d8901f8620fd1f3dc20d6be303aa7dabca
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
Takashi Kajinami