I needed to update some VDPA functests as they were verifying a Yoga compute
service.

NOTE(sbauza): For the moment, the grenade-skip-level is not voting but it
will be done once I2b21e7d5f487f65ce4391f5c934046552d01a1e2 is merged.

Change-Id: I8ef2a8f251a3142c359e14841459bffcc3b50ac9

Also did a bit of cleanup in the text message to tell *when* we need to bump
the min service version.
Given 2023.1 is our first SLURP release, we need to clarify the level of
support we now have for rolling upgrades.

Next cycle, we should update the min version to be Zed.

Change-Id: I2dd906f34118da02783bb7755e0d6c2a2b88eb5d

We do run update_available_resource() synchronously during service
startup, but we only allow certain exceptions to abort startup. This
makes us abort for InvalidConfiguration, and makes the resource
tracker raise that for the case where the compute node create failed
due to a duplicate entry.

This also modifies the object to raise a nova-specific error for that
condition to avoid the compute node needing to import oslo_db stuff
just to be able to catch it.

Change-Id: I5de98e6fe52e45996bc2e1014fa8a09a2de53682

Related to the bp/allowing-target-state-for-evacuate. This change
is extending compute API to accept a new argument targetState.

The targetState argument when set will force state of an evacuated
instance to the destination host.

Signed-off-by: Sahid Orentino Ferdjaoui <sahid.ferdjaoui@industrialdiscipline.com>
Change-Id: I9660d42937ad62d647afc6be965f166cc5631392

This makes the resource tracker look up and create ComputeNode objects
by uuid instead of nodename. For drivers like ironic that already
provide 'uuid' in the resources dict, we can use that. For those
that do not, we force the uuid to be the locally-persisted node
uuid, and use that to find/create the ComputeNode object.

A (happy) side-effect of this is that if we find a deleted compute
node object that matches that of our hypervisor, we undelete it
instead of re-creating one with a new uuid, which may clash with our
old one. This means we remove some of the special-casing of ironic
rebalance, although the tests for that still largely stay the same.

Change-Id: I6a582a38c302fd1554a49abc38cfeda7c324d911

If we start up from an older service version, we need to look at the
database to determine what our node is and write it locally. This
leap of faith will be the last time we need to look up our node based
on our hostname. Instead of relying on this, operators can (ideally)
pre-populate the compute node identities for maximum safety.

Change-Id: I178700bf5ba172603593b1c9972520d05face849

A new configuration option [filter_scheduler]pci_in_placement is added
that allows enabling the scheduler logic for PCI device handling in
Placement for flavor based PCI requests.

blueprint: pci-device-tracking-in-placement
Change-Id: I5ddf6d3cdc7e05cc4914b9b1e762fa02a5c7c550

This patch adds support for cold migrate, and resize with PCI
devices when the placement tracking is enabled.

Same host resize, evacuate and unshelve will be supported by subsequent
patches. Live migration was not supported with flavor based PCI requests
before so it won't be supported now either.

blueprint: pci-device-tracking-in-placement
Change-Id: I8eec331ab3c30e5958ed19c173eff9998c1f41b0

The [pci]alias configuration option now accepts two new optional fields:

* resource_class: that can be used to request PCI device by placement
  RC name.

* traits: a comma separated list of placement trait names that can be
  used to filter placement PCI resource provider by traits.

These fields has the matching counterpart in [pci]device_spec
implemented already.

These fields are matched by the Placement GET allocation_candidates
query therefore these fields are ignored when PCI device pools are
matched against IntancePCIRequest by nova.

Note that InstancePCIRequest object spec field is defined as a list of
dicts. But in reality nova creates the request always with a single
dict. So we restricted the placement logic to handle a single spec.

blueprint: pci-device-tracking-in-placement
Change-Id: I5c8f05c3c5d7597175e60b29e4ab2f22e6496ecd

This patch adds logic to the RequestSpec creation to translate
InstancePCIRequests created from Flavor to RequestGroup objects.

This is just the first step to provide the full scheduling support for
PCI in placement. The missing pieces will come in subsequent patches:

* support user defined resource class and traits in the PCI alias
* filter the allocation candidates returned by placement during
  PciDeviceStats.support_requests() during scheduling and PCI claim
* make sure that the PCI claim always consumes the device that was
  allocated during scheduling

blueprint: pci-device-tracking-in-placement
Change-Id: Ied63221451e2412d8ee2d6b0ba6ec9cd796878b7