COMPUTE_SHARE_LOCAL_FS allows us to report this trait and use
it to filter hosts that support sharing local FS.
Implements: blueprint virtiofs-scaphandre
Change-Id: I7d3aee17b9afab5820735f5bdbb5fe69391dce45
These traits indicate the pass-through or emulated
mode of the guest physical address bits.
blueprint: libvirt-maxphysaddr-support
Signed-off-by: Nobuhiro MIKI <nmiki@yahoo-corp.jp>
Change-Id: Id3716ea9d8581b3c41604f35ed83fa41a3ce0554
This will be used by nova implementing PCI tracking in Placement along
with the existing OWNER_NOVA trait to indicate that an RP has
inventories of nova managed PCI device (or its children devices).
blueprint: pci-device-tracking-in-placement
Change-Id: Id0c87f3afc223f655a708d7d08df62216d832203
COMPUTE_STORAGE_VIRTIO_FS allows us to report this trait and use
it to filter hosts that support virtio filesystems.
COMPUTE_MEM_BACKING_FILE allows us to report this trait and use
it to filter hosts that supports file-backed memory.
These both traits are necessary to support sharing files with
virtiofs and so forth with manila shares.
Implements: blueprint libvirt-virtiofs-attach-manila-shares
Change-Id: I89419cf1649f48106d84cc84e688df7a065f470a
Instances with VNIC_TYPE_SMARTNIC port need PCI devices tagged as
"remote_managed" in the PCI whitelist, however, not all compute drivers
may support the necessary functionality or have the necessary devices.
A new trait is added in order to allow a pre-filter based on it to be
implemented to avoid considering compute hosts that do not support
"remote_managed" ports.
Implements: blueprint integration-with-off-path-network-backends
Needed-By: I168d3ccc914f25a3d4255c9b319ee6b91a2f66e2
Change-Id: If5a4c81084ff9f9f8fecf9fa4cd62fc98e3efcd9
Task: 44048
Story: 2009706
The new trait will be used to signal that compute hosts can honor the
new `socket` value of hw_pci_numa_affinity_policy. It will be helpful
in rolling upgrade scenarios, mixed hypervisor clouds, and just to
make scheduling faster.
Implements: blueprint pci-socket-affinity
Change-Id: Ia4d1871b719037174506fb784b77572e63303762
When a Cyborg device profile name is present in the flavor, the
conductor will initiate creation and binding of accelerator requests,
and the compute manager must wait for the ARQ binding notifications.
In a deployment where the conductor is new, but one or more compute
managers are older than the needed version, this flow will break.
To prevent that: (a) the compute manager publishes this trait,
and (b) the scheduler factors this trait in the Placement query, so
that older compute nodes are not included in allocation candidates.
Change-Id: I6dc00248b54f3a8a5d5dae284d2182df5ba550ab
This change adds the COMPUTE_RESCUE_BFV trait for use when attempting to
rescue boot from volume instances.
Partial-Implements: blueprint virt-bfv-instance-rescue
Change-Id: Ida736058100b5a724da7156399b0c67a9854a806
This adds a compute capability trait to model the
nova ComputeDriver supports_migrate_to_same_host capability [1].
There is a latent bug in nova where configuring the
allow_resize_to_same_host option to True can potentially
lead the scheduler to pick the same host the server is on
to start a cold migration which is only supported by the
(in-tree) vCenter driver (since that driver manages a vCenter
cluster of ESXi hosts). This can lead to at best the cold migration
flow picking an alternate host and at worst failing the cold migration.
Either is not desirable if nova could make a better decision during
scheduling by asking placement for only compute nodes that support
this type of operation.
In absence of the trait, nova can workaround the issue with a
config option [2] such that when cold migrating the API can determine
if the current host that the instance is on should be ignored during
scheduling. With the trait, nova could deprecate and remove that workaround
by having the compute API determine if the host that the instance is on
is suitable for same-host cold migration by finding the provider using
the ComputeNode related to the instance (via host/node on the instance)
and if that provider has the COMPUTE_SAME_HOST_COLD_MIGRATE trait [3]. That
would still leave the nova scheduler to filter out allocation candidates
using the RequestSpec.ignore_hosts list as it does today but it's better
than using a global config option in the API which could be wrong for a
mixed hypervisor deployment.
[1] https://github.com/openstack/nova/blob/19.0.0/nova/virt/driver.py#L153
[2] https://review.opendev.org/676022/
[3] https://review.opendev.org/695220/
Change-Id: I29ef5c402e0d006518bfce14f616e58f85ce7c9d
Related-Bug: #1748697
We have at least one use case [1] for identifying resource providers
which represent compute nodes. There are a few ways we could do that
hackishly (e.g. [2], [3]) but the clean way is to have nova-compute mark
the provider with a trait, since nova-compute knows which one it is
anyway.
This commit adds a COMPUTE_NODE trait for this purpose.
[1] https://review.opendev.org/#/c/670112/7/nova/cmd/manage.py@2921
[2] Assume a provider with a certain resource class, like MEMORY_MB, is
always a compute node. This is not necessarily future-proof (maybe all
MEMORY_MB will someday reside on NUMA node providers; similar for other
resource classes) and isn't necessarily true in all cases today anyway
(ironic nodes don't have MEMORY_MB inventory) and there's also currently
no easy way to query for that (GET /resource_providers?MEMORY_MB:1 won't
return "full" providers, and you can't ask for :0).
[3] Assume a root provider without the MISC_SHARES_VIA_AGGREGATE trait
is a compute node. This assumes you're only using placement for nova-ish
things.
Change-Id: I036dd5cab15144447df5346814d5f0e8fd91135d
This mirrors the compute driver "supports_trusted_certs"
capability added to nova in change:
Ie3130e104d7ca80289f1bd9f0fee9a7a198c263c
This is something validated during server creation
and if the user requests trusted image cert validation
but the driver does not support it, the create request
on that host fails. We eventually want to publish these
driver capabilities as traits so we can optimize scheduling
to avoid those types of capabilities-based build failures:
I15364d37fb7426f4eec00ca4eaf99bec50e964b6
Related to blueprint nova-validate-certificates
Change-Id: I0a67ce94b03b5707802935ddd36aedc622fe12fe
The virt driver API in nova has a capabilities dict that lists the
capabilities of the virt driver.
Based on the patch at https://review.openstack.org/#/c/538498/6, let's
try to standardize the relevant capabilities into a new
os_traits.compute module.
Change-Id: I77f2c4c696010dfe25d3282374dac702b08abaa6
René Ribaud