In a new microversion (1.22) expose support for processing
forbidden traits in GET /resource_providers and GET
/allocation_candidates. A forbidden trait is expressed as
part of the required parameter with a "!" prefix:
required=CUSTOM_FAST,!CUSTOM_SLOW
This change uses db and query processing code adjustments
already present in the code but guarded by a flag. If the
currently requested microversion matches 1.22 or beyond
that flag is True, otherwise False.
Reno, api-ref update and api history update are included.
Because this microversion changes the value of an existing
parameter it was unclear how to best express that in the
api-ref. In this case existing parameter references were
annotated.
Partially implements blueprint placement-forbidden-traits
Change-Id: I43e92bc5f97db7a2b09e64c6cb953c07d0561e63
Adjust the generated SQL and surrounding python code to support
expressing forbidden traits when requesting allocation candidates.
Any resource provider which has a forbidden trait will not be
included.
The RequestGroup object now supports a forbidden_traits attribute.
Code in forthcoming patches will adjust the query string processing
that creates a RequestGroup to set that attribute if the calling code
is using the right microversion.
Partially implements blueprint placement-forbidden-traits
Change-Id: I53f6fce0810c53551710407df7ab1689282e73f3
This is the db-side work for filtering resource providers by
forbidden traits. Since we control whether forbidden is allowed
or not at the API layer, we can add support here in the DB layer
such that it works all the time.
Subsequent patches will turn on the the functionality in a microversion.
Partially implements blueprint placement-forbidden-traits
Change-Id: I46796d49931df20b002d1a7e6bb3a6be34dabefa
Add support to parse_qs_request_groups to optionally process the
"required" parameter for forbidden traits, expressed as the
normal trait form prefixed with "!". The parsing removes "!"
prefixed traits from the required_traits attribute on a
RequestGroup and puts them (without the "!") in a new
forbidden_traits attribute.
The optionality allows the caller to control the processing
based on the microversion. Later code will add that to
the list resource providers and list allocation canidates
handler code, in the same microversion.
This allows declaring forbidden handling only at the API layer.
Subsequent patches will turn on forbidden handling in the object/
data layer but no forbidden traits will reach that layer until
the microversion turns on allow_forbidden in the API.
Partially implements blueprint placement-forbidden-traits
Change-Id: Icc9dc2631a0eca9e998b9ce8706c7b6920e0cb69
Two issues here:
- The mock library provides a 'mock_open' function to mock the 'open'
builtin's context manager. We should have been using this but were
not.
- We were mocking another context manager in a fairly strange way. This
seems to be causing issues, possibly down to race. We shouldn't do
that.
Fix both issues.
Change-Id: I289b56ae3f9ccd16d72b2ca317e68e6c18b8b313
Fixes-Bug: #1763535
host arg will be used to check libvirt and QEMU version.
Change-Id: Ib592065e8088a0cb45e95eb1501ff4aa32715206
Signed-off-by: Sahid Orentino Ferdjaoui <sahid.ferdjaoui@redhat.com>
This will be used outside the libvirt driver itself in subsequent
patches, so this is factoring it out so it can be used elsewhere
instead of duplicating it.
Signed-off-by: Sahid Orentino Ferdjaoui <sahid.ferdjaoui@redhat.com>
Change-Id: I2e77d7ae3666a4ce9e256f7757b5d3c6ba2495dd
I am unsure if I should be concerned about the lack of error
checking here, but this is how it was originally.
Change-Id: I9c1dfd5a90a53d90a44baae4874965bf8f48cea1
blueprint: hurrah-for-privsep
I can't see a good reason for the two drivers to use different
flags, and this simplifies the code a little.
Change-Id: I55cdc22ce8f95dff0cfd1a31b58582fc4b3ea48f
blueprint: hurrah-for-privsep-again
The same pattern as the rest of the changes. This means that privsep now
needs to let you pass flags to e2fsck, which I don't love and will remove
in a later patch.
Change-Id: I6c695c04ae586fec6adc354257638116277dda88
blueprint: hurrah-for-privsep
If the instance is rebuilt with a different image in the same
host, we don't need to call placement because there is no change
in resource consumption.
Change-Id: Ie252271ecfd38a0a1c61c26e323cc03869889f0a
Closes-Bug: #1750623
For in-tree job definitions, the job is branch-specific
by design, so we don't need the stable branch exclusion
specifier as it won't run on those branches anyway since
it's not defined for those branches.
Related to https://storyboard.openstack.org/#!/story/2001839
Related-Bug: #1763382
Change-Id: I78dead482e2ed8262745cb08c9f4ab71035adb33
Since Icb971831c8d4fe5f940d9e7993d53f1c3765e30f merged
in devstack to use the Queens UCA, the nova-multiattach
job has been failing to start nova-compute due to permission
errors connecting to libvirt, which probably has something
to do with the stack user not having access to the proper
libvirt(d) group.
It's weird since this was working in change
I0962474ff6dfc5fa97670c09a1af97a0f34cd54f to make the
nova-multiattach job use the Queens UCA.
Anyway, let's make it non-voting to stop the bleeding while
we can figure out the actual problem.
Change-Id: I3911c902cecfa8e66fccffd9fe0e4f462eacd588
Related-Bug: #1763382
ec2 was deprecated in commit
f098398a83
back to mitaka release, this patch
starts to remove ec2 services in nova.
Change-Id: I5939ef73904f1bb66ed8453c900bfb50cdb5b8b6
Replace stubs.Set with stub_out or mock in
nova/tests/unit/api/openstack/compute/test_neutron_security_groups.py.
The 'fake_get_instances_security_groups_bindings' method
in nova/tests/unit/api/openstack/compute/test_security_groups.py
is only used in test_neutron_security_groups.py.
So the method is moved to test_neutron_security_groups.py.
Change-Id: Ia2857d51f65f2acb0d22bb873461a50f8c9f9ba4
Implements: blueprint mox-removal
This was initially added in change I1127e31d86a061a93a64ee1eb4a4d900d8bf49b5
but is no longer used anywhere in nova since change
Ic18017a16c5bffee85a43db65ff17283599a27ba.
Anyway, this change still allows it to be passed as a kwarg for now but will
emit a UserWarning if it is, and then we can make it a hard failure starting
in the S release.
Change-Id: Ib0b23a47c2e833073108af6700b16f8026631a83
The assertion in the test that the migration status is 'completed'
is flawed in that it assumes when the instance status is 'ACTIVE'
the migration is completed, which isn't True, since the instance
status gets changed before the migration is completed, but they are
very close in time so there is a race, which is how this test slipped
by. This fixes the issue by polling the migration status until it
is actually completed or we timeout.
Change-Id: I61f745667f4c003d7e3ca6f2f9a99194930ac892
Closes-Bug: #1762876
During development of update_provider_tree, it was decided that we don't
need it to return anything - deciding whether things have changed is
handled by the report client.
But somehow we missed removing that bit from the docstring. This patch
remedies that.
related to blueprint update-provider-tree
Change-Id: I199a13b0a3de9f1cbe3f6419506fe7b37ed6c4ae
Chris Dent