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
In Zed cycle, we have dropped the python 3.6/3.7[1] testing
and its support. Moving the py36 job to py38 based as well as
updating the python classifier also to reflect the same.
[1] https://governance.openstack.org/tc/reference/runtimes/zed.html
Change-Id: I6db7cdd34d5c51a27673396b870ca571ad52cb43
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>
Setuptools v54.1.0 introduces a warning that the use of dash-separated
options in 'setup.cfg' will not be supported in a future version [1].
Get ahead of the issue by replacing the dashes with underscores. Without
this, we see 'UserWarning' messages like the following on new enough
versions of setuptools:
UserWarning: Usage of dash-separated 'description-file' will not be
supported in future versions. Please use the underscore name
'description_file' instead
[1] https://github.com/pypa/setuptools/commit/a2e9ae4cb
Signed-off-by: Takashi Natsume <takanattie@gmail.com>
Change-Id: I26fffc6e83581fd8babc2d64481e2700896c9112
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>
Switch to openstackdocstheme 2.2.1 and reno 3.1.0 versions. Using
these versions will allow especially:
* Linking from HTML to PDF document
* Allow parallel building of documents
* Fix some rendering problems
Update Sphinx version as well.
Disable openstackdocs_auto_name to use 'project' variable as name.
Change pygments_style to 'native' since old theme version always used
'native' and the theme now respects the setting and using 'sphinx' can
lead to some strange rendering.
openstackdocstheme renames some variables, so follow the renames
before the next release removes them. A couple of variables are also
not needed anymore, remove them.
See also
http://lists.openstack.org/pipermail/openstack-discuss/2020-May/014971.html
Change-Id: Id6a7a465630647382de63be64fc16f6e4f52912d
These translation sections are not needed anymore, Babel can
generate translation files without them.
Change-Id: I62f884243e7cab71b3efad85676cdf6171e9a644
flake8 new release 3.8.0 added new checks and gate pep8
job start failing. hacking 3.0.1 fix the pinning of flake8 to
avoid bringing in a new version with new checks.
Though it is fixed in latest hacking but 2.0 and 3.0 has cap for
flake8 as <4.0.0 which mean flake8 new version 3.9.0 can also
break the pep8 job if new check are added.
To avoid similar gate break in future, we need to bump the hacking min
version.
- http://lists.openstack.org/pipermail/openstack-discuss/2020-May/014828.html
Change-Id: I44e32f59e0d6d7c7d96472476db6c14e9dae0140
This repo is now testing only with Python 3, so let's make
a few cleanups:
- Remove python 2.7 stanza from setup.py
- Switch to using sphinx-build
- Cleanup doc/source/conf.py to remove now obsolete content.
- Use newer openstackdocstheme version
- Switch to hacking 3.0
Change-Id: Id3a7e6b6a6160358efb897cbf73630d96672d4fb
This supports Python 3 goodness. Some additional tox and gitignore
tweaks are included while we're here.
Change-Id: Id1a7a90119be242486584a3b5d6939083bfac84d
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>
We call 'sphinx-build' directly now. No need to keep this legacy
configuration around.
Change-Id: I337f9fefe7f0364bce3a0192dfc9c1199076fa02
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
This will prevent setuptools accidentally installing os-traits in a
Python 2 environment.
Change-Id: I4ecd197cfedca74bc8a068edc08c2bc097f41458
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