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
PCI pool filtering only follow the allocation candidate to select which
PCI pool can be used but does not consider how much devices should be
consumed from which pool.
blueprint: pci-device-tracking-in-placement
Change-Id: I97851180b7af275ea7e4c175be6056130906af87
As this util func is used both for device_spec and PCI alias config in
the functional test it is renamed to fit for both use.
Change-Id: I7abe2038680f6a7ec08da1a8a9ba22a04949f37d
A new configuration option [filter_scheduler]pci_in_placement is added
that allows enabling the scheduler logic for PCI device handling in
Placement for flavor based PCI requests.
blueprint: pci-device-tracking-in-placement
Change-Id: I5ddf6d3cdc7e05cc4914b9b1e762fa02a5c7c550
We recently discovered that when the perfect conditions are present
where:
* libguestfs-dev/el and guestfs python bindings are installed
and
* unit tests are not being run in a venv or guestfs python bindings
are installed in the tox venv
the test will end up loading the guestfs module and try to call the
real guestfs and possibly libvirt and fail because of it.
Our unit tests shouldn't be loading modules like guestfs, so this adds
proper mocking to the test along with a poison fixture that will
prevent future accidental imports of such modules.
Closes-Bug: #1994913
Change-Id: I676ee1fd33cf053681a07448759c28f0f2ad79d1
Id02e445c55fc956965b7d725f0260876d42422f2 added special case in the
healing logic for same host resize. Now that the scheduler also creates
allocation on the destination host during resize we need to make sure
that the drop_move_claim code that runs during revert and confirm drops
the tracked migration from the resource tracker only after the healing
logic run as these migrations being confirmed / reverted are still
affecting PciDevices at this point.
blueprint: pci-device-tracking-in-placement
Change-Id: I6241965fe6c1cc1f2560fcce65d5e32ef308d502
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
Zuul