Use specs.openstack.org consistently and use implemented, not approved,
to show the latest amended spec after actual implementation is done.
Change-Id: Iac3df73568ffbd979dbc012ad75dafc39fd3fd9c
Since the placement project was migrated back from storyboard to
launchpad, a bug should be reported to the placement project in
launchpad.
Change-Id: Ib36a56fa0609ba75312198853fc1d697057807fd
As per the current release tested runtime, we test
till python 3.11 so updating the same in python
classifier in setup.cfg
Change-Id: Icb71bc5f52eb48d3870325d3b9175dcfd580bdc1
pip 23.1 removed the "setup.py install" fallback for projects
that do not have pyproject.toml and now uses a pyproject.toml
which is vendored in pip.
To address that, this change adds the minimal pyproject.toml
to enable pbr to be properly used to build editable wheels.
This is required to support installing devstack on
centos stream 9 and related distros with GLOBAL_VENV=True
Without this change the wsgi scripts are not generated in
editable mode. i.e. pip install -e /opt/stack/keystone
See https://pip.pypa.io/en/stable/news/#v23-1
and https://github.com/pypa/pip/issues/8368 for more
details on the removal of the fallback support.
setuptools v64.0.0 is used to support editable installs
via its PEP-660 implmentation
https://github.com/pypa/setuptools/pull/3488
Change-Id: I50be314d6d2578fa5b7f3a46fb72502d9f38d5e8
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