COMPUTE_NET_VIRTIO_PACKED allows us to report this trait and use it to
filter hosts that support packed virtqueue.
Nova spec: https://review.opendev.org/c/openstack/nova-specs/+/868377
Change-Id: I0752af7b67e999d53f007b3e83ec218bb6fd7da7
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
Add trait to specify whether a driver supports regeneration
of config drives.
Change-Id: I1c63d1edde52e71c571258b87903afaaa26b1c8c
Signed-off-by: Jan Hartkopf <jhartkopf@inovex.de>
Add traits for vIOMMU traits corresponding to the allowed values of
"hw_iommu_model" image metadata property.
Blueprint: libvirt-viommu-device
Change-Id: Ic44429ad360475143b20071f85d534a958d110e0
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
Resources such as vGPU can be managed either by nova
by cyborg. In order to distinguish the manage-owner, use owner (nova, cyborg)
trait in Placement when the inventory is reported.
When resource is requested, flavor based VGPU resource should be allocated
from the nova managed RP, while device profile based VGPU resource should be
allocated from the cyborg managed RP.
Change-Id: Ia50e9a1acdcfb821e2d40774c3dca191e172ca68
Implement new image meta property that allows for the selection of the
correct QEMU binary, cpu architecture, and machine type for a guest
architecture that is different than the host architecture; An x86_64
guest running on an AArch64 host, and vice versa.
Specifically the required OS traits have been added to ensure that the
hw_architecture and hw_emulation_architecture fields recieve the
correct allowed values.
exapnded hw_architecture os_traits to match all specified in nova object
fields.
Depends-On: https://review.opendev.org/c/openstack/nova-specs/+/824044
Implements: blueprint pick-guest-arch-based-on-host-arch-in-libvirt-driver
Closes-Bug: 1863728
Signed-off-by: Jonathan Race <jrace@augusta.edu>
Change-Id: I891cd43b2b97b3774ff923e3487a153a5ba237ef
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 'bochs' display device is a recommended[1] safe option for UEFI
guests.
This lets an admin set the trait either via the flavor extra-specs or
image metadata properties:
trait:COMPUTE_GRAPHICS_MODEL_BOCHS=required
This also allows The libvirt virt dirver report a standard trait
for bochs graphics model support and enables the image_metadata_prefilter
to automatically request the trait. This will enable vm that request
the bochs graphics model to be automaticaly scheduled to hosts that
can support it.
Implements: blueprint add-bochs-display-device
[1]: https://www.kraxel.org/blog/2019/09/display-devices-in-qemu/#tldr
Change-Id: Iba867f4632853f99373976e39c3494ea1c8b91a2
Signed-off-by: Kashyap Chamarthy <kchamart@redhat.com>
This allows us to report this trait and use it to filter out hosts that
support our requested 'hw_firmware_type'.
Change-Id: Ifc06d6f9b1d3217d09fa20aafc2988acb11c80f2
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
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
Introduce a trait, COMPUTE_SECURITY_UEFI_SECURE_BOOT, as discussed in
the Secure Boot spec[1]. (Yeah, it reads a little awkward, not sure if
we can avoid it, as I've included it as part of compute/security.py
file.)
This lets an admin set the trait either via the flavor extra-specs or
image metadata properties:
trait:COMPUTE_SECURITY_UEFI_SECURE_BOOT=required
to request to boot an instance in Secure Boot mode. Nova's libvirt
driver is responsible make sure the compute node has the necessary
capabilities (e.g. relevant libvirt, QEMU, OVMF, EDK2 et al versions).
If the host hypervisor is incapable, the instance creation will fail.
[1] https://opendev.org/openstack/nova-specs/src/branch/master/specs/wallaby/approved/allow-secure-boot-for-qemu-kvm-guests.rst#fnref8
blueprint: allow-secure-boot-for-qemu-kvm-guests
Change-Id: I333147dcd47c6d0b926338a5a0c545f5adc63961
Signed-off-by: Kashyap Chamarthy <kchamart@redhat.com>
We're going to have to switch to something other than a list of strings
or use Sphinx-style inline documentation if we want to provide anything
more useful.
Change-Id: I45c29fe2bdd3fdcb3c69e07f5e9e5be36de9b797
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
Only one user here which is no longer needed in a Python 3 only world.
Change-Id: Iac33e324d07d67368a5b544030cd5414d0586955
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
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
On the theory that they aren't and shouldn't be used, the following
methods are removed from the public interface of the base os_traits
package:
- symbolize (deleted, unused internally)
- import_submodules (deleted, replaced with appropriate call to
_walk_submodules)
This commit also reorganizes the module to put private methods first,
public methods last; and alphabetize within those groupings.
Sem-Ver: api-break
Change-Id: Idb5613bc016743ba689c6996d39399aae774daa9
Add a print_tree method in the base os_traits package. This recursively
walks the repository and prints a formatted tree of short names of all
the namespaces and their traits. You can try it like this:
python -c 'import os_traits; os_traits.print_tree()'
Here's an abbreviated subset of the output:
COMPUTE:
DEVICE_TAGGING, TRUSTED_CERTS
GRAPHICS:
MODEL_CIRRUS, MODEL_GOP, MODEL_NONE, MODEL_QXL, MODEL_VGA, MODEL_VIRTIO, MODEL_VMVGA, MODEL_XEN
HW:
CPU:
HYPERTHREADING
AMD:
SEV
PPC64LE:
POWER8, POWER9
NUMA:
ROOT
MISC:
SHARES_VIA_AGGREGATE
STORAGE:
DISK:
HDD, SSD
Change-Id: I6309501f10544f468bb694361c845a393a9491cf
Add support for HW_CPU_PPC64LE_POWER8 and HW_CPU_PPC64LE_POWER9
so that trait-based, multi-architecture scheduling can occur.
Change-Id: Iacf23524434b2b9fb7d02d565618e515e77a1baa
Adds a comment with a link to the spec for the recently-added
COMPUTE_MIGRATE_AUTO_CONVERGE and COMPUTE_MIGRATE_POST_COPY traits.
blueprint expose-auto-converge-post-copy
Change-Id: I89a67614cbd2da2840dc9f6a2fdf4f4633ca149f
Add a new standard trait HW_CPU_X86_AVX512VNNI for the support
of CPU AVX512-VNNI instructions.
AVX512-VNNI is the vector network instruction set which is described in
https://en.wikipedia.org/wiki/AVX-512#New_instructions_in_AVX-512_VNNI.
Change-Id: Id12ed38c1648b006c20cf5875a9b2ffe1690ecd6
This will be used by nova to signal when a compute node
resource provider is disabled so that a placement request
pre-filter in the nova scheduler can ask placement to filter
out compute node allocation candidates that are disabled,
similar to the post-placement ComputeFilter.
Part of nova blueprint pre-filter-disabled-computes
Change-Id: Ia8e4487bfb59f764a6817ec8650785ffa902eab5
This change extends the COMPUTE_GRAPHICS
module with 3 new traits for the GOP, NONE and
VIRTIO models.
Depends-On: https://review.opendev.org/#/c/647733/
Change-Id: I17945e8ad6ea5349f46c26e427a0f539ca5eba8b
Task: 30526
Story: 2005447
- This change introduces standard traits for the
well defined hw_disk_model, hw_cdrom_model, hw_video_model
and hw_vif_model image metadata properties.
- This spec defines all of the new traits in the compute
namespace as they represent the ability of a hypervisor to
emulate a specific virtual device model, not the presence
of the respective hardware device on the host.
Change-Id: I42237b196644bfa87701f978a1519941d447b450
Task: 30526
Story: 2005447
Introduce trait HW_NUMA_ROOT. This is to be used with the 'resourceless
RP' and 'same_subtree' placement features [1] when requesting NUMA
affinity (e.g. multiple devices affined to the same NUMA node)
especially when not requesting resources from the subtree root provider
itself.
[1] https://review.opendev.org/#/c/662191/
Change-Id: If5478e797b7bec2d8ebe78dd959dcf179a2834f4
Story: #2005575
Task: #30908
The main motivation for this change is to: (a) add missing CPU flags
(including those flags that provide mitigation for the recent CVE flaws)
as 'traits'; and (b) adjust and clean up the layout of the 'hw/cpu/'
directory.
To that end, the following are the set of changes in this patch.
(*) Introduce a new cpu/x86 directory; and vendor-specific files: amd.py
and intel.py; with __init__.py containing the *common* stuff:
- hw/cpu/x86/amd.py -- AMD-only traits.
- hw/cpu/x86/intel.py -- Intel-only traits.
- hw/cpu/x86/__init__.py -- Common traits for both AMD and Intel.
- hw/cpu/x86.py -- Two things: (a) move the contents of this file
into x86/__init__.py, which is its new location; this move
preserves the integrity of the string trait names and Python
paths, as they were before; and (b) given point (a), remove the
now no longer needed hw/cpu/x86.py. (Justification: We are
removing this file to maintain consistency with the way it's done
througout the 'os-traits' repository.)
- hw/cpu/amd.py -- Deprecate the contents of this file with a
comment; and copy them into hw/cpu/x86/amd.py, which is its new
location.
Comparison between the old and the new layouts of os_traits/hw/cpu/:
Old Layout New Layout
---------- ----------
cpu/ cpu/
├── aarch64.py ├── aarch64.py
├── amd.py ├── amd.py [DEPRECATED]
├── __init__.py ├── __init__.py
└── x86.py └── x86/
├── amd.py
├── __init__.py
└── intel.py
(*) Add various missing CPU flags to x86/intel.py, x86/amd.py and to
x86/__intel__.py.
(*) Copy, and deprecate with a comment, flags from cpu/x86.py, i.e..
"VMX" (Intel) and "SVM" (AMD), into corresponding vendor-specific
files.
References
----------
[1] Thread start:
http://lists.openstack.org/pipermail/openstack-discuss/2019-May/006281.html
-- On reporting CPU flags that provide mitiation (to CVE flaws) as
Nova 'traits'
[2] Thread conclusion:
http://lists.openstack.org/pipermail/openstack-discuss/2019-May/006364.html
Closes-Bug: #1830948
Change-Id: I1c9a72d19ef9dadfb931efa3894867099974bcc7
Signed-off-by: Kashyap Chamarthy <kchamart@redhat.com>
Adds a comment to the compute.image module proposed in [1] providing
context on where the values were derived from, and that they should be
kept in sync in the (perhaps unlikely) event that more image types are
added in the future.
[1] I2a76e6b1062b0112faec73cef4a369124e45aa98
Change-Id: I1f0d79e3e77d23d3a190bad594c504ef5503cc67
These are traits used to represent Glance image types that may be supported
by a service such as nova-compute. Glance defines these types rigidly in
their documentation:
https://docs.openstack.org/image-guide/image-formats.html#disk-formats
and thus they should be stable and standardized for use in placement
queries.
Change-Id: I2a76e6b1062b0112faec73cef4a369124e45aa98