As discussed in PTG, we need to test the new RBAC in the
integrated gate and accordingly enable the new defaults
and scope check by default. A new integrated testing job
has been added and results show that the new defaults and
scope checks are working fine. During testing, we found a
few bugs in neutron policies but all are fixed now.
enforce_scope and enforce_new_defaults are oslo policy config
options but they are per service level and the default value
can be overridden. Oslo policy 3.11.0 version allows to override
the default value for these config options[1] so upgrading the
oslo policy version in requirements.txt
Depends-On: https://review.opendev.org/c/openstack/devstack/+/869781
Depends-On: https://review.opendev.org/c/openstack/placement/+/869525
[1] https://github.com/openstack/oslo.policy/blob/3.11.0/oslo_policy/opts.py#L125
Change-Id: I977b2daedf880229c8d364ca011f2ea965b86e3a
It seems that with tox 4.2.6 the missing interpreter error was fixed but
the generative testenv feature is broken and the
[testenv:functional{,-py38,-py39,-py310}] format is leads to missing
interpreter error. It is due to a conflict between basepython = python3
and the version fragment in the generative target suppressed by
ignore_basepython_conflict = true.
This patch removes basepython = python3 assuming that developers already
switched for python3 in their environment as python2.7 is EOL.
Also we took the opportunity to add the global constraints via the
install_command instead of deps as deps is not used during the
installation of the editable package.
Change-Id: I258a7c13434b29402804181dea275b42d5539df0
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
This patch adds various functional test cases showing that the placement
allocation candidate restricts the available PCI pools during the run of
the filter scheduler and that the placement PCI allocation later drives
the PCI claim code in the compute.
blueprint: pci-device-tracking-in-placement
Change-Id: If46ee131a9e5499ae91da93ddaac88aa49182f56
After the scheduler selected a target host and allocated an allocation
candidate that is passed the filters nova need to make sure that PCI
claim will allocate the real PCI devices from the RP which is allocated
in placement. Placement returns the request group - provider mapping for
each allocation candidate so nova can map which InstancePCIRequest was
fulfilled from which RP in the selected allocation candidate. This
mapping is then recorded in the InstancePCIRequest object and used
during the PCI claim to filter for PCI pools that can be used to claim
PCI devices from.
blueprint: pci-device-tracking-in-placement
Change-Id: I18bb31e23cc014411db68c31317ed983886d1a8e
After a baremetal instance is deleted, and its allocation is removed
in placement, the ironic node might start cleaning. Eventually nova
will notice and update the inventory to be reserved.
During this window, a new instance may have already picked this
ironic node.
When that race happens today the build fails with an error:
"Failed to reserve node ..."
This change tries to ensure the remaining alternative hosts are
attempted before aborting the build.
Clearly the race is still there, but this makes it less painful.
Related-Bug: #1974070
Change-Id: Ie5cdc17219c86927ab3769605808cb9d9fa9fa4d
While collecting information because of a question I received
about soft delete and shadow tables I realized that the documentation
contains bits and pieces here and there, but I couldn't find more.
This change summarizes what I found from docs and asking around.
I hope you find it useful.
Change-Id: I5ff90224cc27c57dc463604559d25298ed7b3f98
Unlike uwsgi, apache mod_wsgi does not support passing
commandline arguments to the python wsgi script it invokes.
As a result while you can pass --config-file when hosting the
api and metadata wsgi applications with uwsgi there is no
way to use multiple config files with mod_wsgi.
This change mirrors how this is supported in keystone today
by intoducing a new OS_NOVA_CONFIG_FILES env var to allow
operators to optional pass a ';' delimited list of config
files to load.
This change also add docs for this env var and the existing
undocumented OS_NOVA_CONFIG_DIR.
Closes-Bug: 1994056
Change-Id: I8e3ccd75cbb7f2e132b403cb38022787c2c0a37b
For networks with subnets with enabled DHCP service don't provide
mtu value in the metadata. That way cloud-init will not configure it
"statically" in e.g. netplan's config file and guest OS will use MTU
value provided by the DHCP service.
Closes-Bug: #1899487
Change-Id: Ib775c2210349b72b3dc033554ac6d8b35b8d2d79
Added check if quiesce fails because libvirt fails to connect with
qemu guest agent inside instance
Closes-Bug: #1980720
Change-Id: I134a4060ace2678f76ae3606bf117c07194a8d92
A few tests related to volume detach are timeout in
nova-lvm job (failing 100%[1]). Root cause of timeout is not
known and it may take time to find and fix the issue. To unblock
gate and keep runing rest of the tests in lvm job, let's skip
the failing tests until they are fixed.
Related-Bug: #1998148
[1] https://zuul.opendev.org/t/openstack/builds?job_name=nova-lvm&branch=master&skip=0
Change-Id: Id29ce352df84168d0a45512e2c59820aefc75943
As per 2023.1 testing runtime[1], we need to test on Ubuntu
Jammy (which will be taken care by tempest and devstack patches
to move base jobs to Jammy) and at least single job to run on
Ubutnu Focal (for smooth upgrade). Also, python 3.10 testing is
voting now.
This commit adds a new job to run on focal which can be removed
in future cycle when testing runtime drop the requirement of Focal
testing. Also, make python 3.10 functional and unit test job as voting
(openstack-tox-py310 is running as part of generic template so we do
not need to explicitly add that)
[1] https://governance.openstack.org/tc/reference/runtimes/2023.1.html
Change-Id: Ia43f73dba00b0b5932939bcc7d11b97a83072ee3
Libvirt 7.7 changed the mdev device naming to include the parent PCI
device when listing node devices. The domain, however, will still only
see the UUID and not see the parent PCI device. Changing the parsing to
simply drop the PCI identifier is not enough as the device cannot be
found when attempting to lookup the new ID.
Modify the Libvirt Driver's _get_mediated_device_information to tolerate
different formats of the mdev name. This first uses the legacy behavior
by trying to lookup the device name that is passed in (typically
mdev_<uuid> format) and if that is not found, iterates the list of mdev
node devices until the right UUID is found and selects that one.
Note that the lookup of the mdev device by UUID are needed in order
to keep the ability to recreate assigned mediated devices on a reboot of
the compute node.
Additionally, the libvirt utils parsing method mdev_name2uuid, has
been updated to tolerate both mdev_<uuid> and mdev_<uuid>_<pciid>
formats.
Closes-Bug: 1951656
Change-Id: Ifed0fa16053228990a6a8df8d4c666521db7e329
Ghanshyam Mann