The document doesn't follow previous pattern to guide use
in using nova user to execute command and lead to issue
Change-Id: I795706a8f78ab4154bd39ce6259901800b34890e
Closes-Bug: 1781573
In the baremetal use case, it is necessary to allow a remote
source of truth assert information about a physical node,
as opposed to a client asserting desired configuration.
As such, the prepare_networks_before_block_device_mapping virt
driver method was added, however in doing so network VIF attaching
was moved before actual hardware reservation. As ironic only
supports users to have a number of VIFs limited by the number
of network interfaces in the physical node, VIF attach actions
cannot be performed without first asserting control over the node.
Adding an "instance_uuid" upfront allows other ironic API consumers
to be aware that a node is now in use. Alternatively it also allows
nova to become aware prior to adding network information on the node
that the node may already be in use by an external user.
Co-Authored-By: Julia Kreger <juliaashleykreger@gmail.com>
Change-Id: I87f085589bb663c519650f307f25d087c88bbdb1
Closes-Bug: #1766301
If we're updating existing allocations for an instance due
to the project_id/user_id not matching the instance, we should
use the consumer_generation parameter, new in placement 1.28,
to ensure we don't overwrite the allocations while another
process is updating them.
As a result, the include_project_user kwarg to method
get_allocations_for_consumer is removed since nothing else
is using it now, and the minimum required version of placement
checked by nova-status is updated to 1.28.
Change-Id: I4d5f26061594fa9863c1110e6152069e44168cc3
Change I9c2111f7377df65c1fc3c72323f85483b3295989 sets the
RequestSpec.is_bfv flag for newly created instances so
that scheduling (using placement) does not allocate DISK_GB
resources for the Flavor's root_gb when booting from volume.
RequestSpecs for old instances created before that change will
not have the is_bfv field set, so this change adds a check for
that in the various move operations (evacuate, unshelve, cold
migrate and live migrate) and sets the RequestSpec.is_bfv flag
accordingly.
The related functional test is updated for the legacy cold
migrate and heal scenario.
Change-Id: I8e529ad4d707b2ad012328993892db83ce464c4b
Closes-Bug: #1469179
hypervisor local_gb_used still reports usage even with volume-backed
instances after fix for bug 1469179.
This is because of some code in the resource tracker that is not
boot-from-volume aware when reporting disk usage, it just gets the
root_gb off the flavor:
https://github.com/openstack/nova/blob/eb4f65a7951e921b1cd8d05713e144e72f2f254f/nova/compute/resource_tracker.py#L1455
This patch simply check if the instance is bfv before returning
the result. If it's a volume-backed instance and report 0 for root_gb if
that's the case.
Change-Id: I0839470c4bcfb16590a0d87b306d683b059bf8a9
Closes-bug: #1782393
When detaching a device from a domain we first attempt to remove the
device from both the persistent and live configs before looping to
ensure the device has really been detached from the running live config.
Previously when this failed we logged an error message that suggested
that this was due to issues detaching the device from a transient
domain, however this is not the case as the domain is persistent.
This change simply updates the error and associated comments to only
reference the live config of the domain.
Additionally a DEBUG line claiming that a device has been successfully
detached is now only logged once the device is removed from the live
config, hopefully avoiding any confusion from this line been logged
each time an attempt is made to detach the device.
Change-Id: If869470216600c303d47cf79f12c4fc88abcf813
Keystone deprecated 'auth_uri' to bring 'www_authenticate_uri' in
https://review.openstack.org/#/c/508522/, so 'auth_uri'
should be removed from all openstack projects.
The auth_url is the parameter passed to the keystoneauth plugin
and the auth_uri is the parameter specific to keystonemiddleware,
so the auth_url would be appropriate in api/client since that's
going to be passed straight to keystoneauth, and it should be
the same in api/client and in the fixture. So we change the
parameter to auth_url in api/client instead of www_authenticate_uri.
Change-Id: I7f878974fe8bebb8fe5803ca4e2f8839cdc971d0
Related-Bug: 1755728
Change I9c2111f7377df65c1fc3c72323f85483b3295989 fixed it so we stop
allocating the flavor's root_gb if we're booting from volume. However,
we're still reporting it against the compute node's capacity.
Furthermore, we're not reporting swap space at all.
This adds functional test coverage demonstrating these bugs.
Change-Id: Ia46754d8ff65c501545853e6c2909a5a900d45c0
Related-Bug: #1782393
Related-Bug: #1782386
Adds a nova.api.openstack.placement.objects.resource_provider.reshape()
function that accepts a dict, keyed by provider UUID, of inventory
information for a set of providers and an AllocationList object that
contains all of the rejiggered allocation records for all consumers on
the providers involved in the reshape operation.
The reshape() function is decorated with the placement API's DB
transaction context manager which will catch all exceptions and issue a
ROLLBACK of the single writer transaction that is involved in the myriad
sub-operations that happen inside reshape(). Likewise, a single COMMIT
will be executed in the writer transaction when reshape() completes
without an exception.
Change-Id: I527de486eda63b8272ffbfe42f6475907304556c
blueprint: reshape-provider-tree
Split up the evacuate instance documentation into two parts. One
for the existing single instance evacuation and a second new part
for the nova host-evacuate procedure.
Change-Id: Ibcdc2bc3f08e2fab23b9821feae0f489fb64a8f7
Closes-Bug: #1763039
Update aggregate-related scheduler report client methods to use
placement microversion 1.19, which returns provider generation in GET
/rps/{u}/aggregates and handles generation conflicts in PUT
/rps/{u}/aggregates. Helper methods previously returning aggregates and
traits now also return the generation, which is fed through
appropriately to subsequent calls. As a result, the generation kwarg is
no longer needed in _refresh_associations, so it is removed.
Doing this exposes the race described in the cited bug, so we add a
retry decorator to the resource tracker's _update and the report
client's aggregate_{add|remove}_host methods.
Related to blueprint placement-aggregate-generation
Closes-Bug: #1779931
Change-Id: I3c5fbb18297db71e682fcddb5bf4536595d92383
Missing print format will cause 'ValueError: unsupported
format character' error, this is to fix it.
Change-Id: I1a18a6357056a3a7bfa729b9fccb288437564937
Before change I4b67ec9dd4ce846a704d0f75ad64c41e693de0fb
the ServerGroupAntiAffinityFilter did not rely on the
HostState.instances dict to determine **within the same
request** how many members of the same anti-affinity
group were on a given host. In fact, at that time, the
HostState.instances dict wasn't updated between filter
runs in the same multi-create request. That was fixed with
change Iacc636fa8a59a9e8670a8d683c10bdbb0dc8237b so that
as we select a host for each group member being created
within a single request, we also update the HostState.instances
dict so the ServerGroupAntiAffinityFilter would have
accurate tracking of which group members were on which
hosts.
However, that did not account for a wrinkle in the filter
added in change Ie016f59f5b98bb9c70b3e33556bd747f79fc77bd
which is needed to allow resizing a server to the same host
when that server is in an anti-affinity group. That wrinkle,
combined with the fact the RequestSpec the filter is acting
upon for a given instance in a multi-create request might
not actually have the same instance_uuid can cause the filter
to think it's in a resize situation and accept a host which
already has another member from the same anti-affinity group
on it, which breaks the anti-affinity policy.
For background, during a multi-create request, we create a
RequestSpec per instance being created, but conductor only
sends the first RequestSpec for the first instance to the
scheduler. This means RequestSpec.num_instances can be >1
and we can be processing the Nth instance in the list during
scheduling but working on a RequestSpec for the first instance.
That is what breaks the resize check in ServerGroupAntiAffinityFilter
with regard to multi-create.
To resolve this, we update the RequestSpec.instance_uuid when
filtering hosts for a given instance but we don't persist that
change to the RequestSpec.
This is a bit clunky, but it kind of comes with the territory of
how we hack scheduling requests together using a single RequestSpec
for multi-create requests. An alternative to this is found in change
I0dd1fa5a70ac169efd509a50b5d69ee5deb8deb7 where we rely on the
RequestSpec.num_instances field to determine if we're in a multi-create
situation, but that has its own flaws because num_instances is
persisted with the RequestSpec which might cause us to re-introduce
bug 1558532 if we're not careful. In that case we'd have to either
(1) stop persisting RequestSpec.num_instances or (2) temporarily
unset it like we do using RequestSpec.reset_forced_destinations()
during move operations.
Co-Authored-By: Sean Mooney <work@seanmooney.info>
Closes-Bug: #1781710
Change-Id: Icba22060cb379ebd5e906981ec283667350b8c5a
The libvirt driver doesn't support resize for lvm-backed instances
so we need to skip this test to get the nova-lvm job to pass again.
Change-Id: Id752b539babadd187b4c999039cc4ca655437d47
Closes-Bug: #1782607
Setting max_placement_results will make force_host invaild sometimes,
especially in large-scale enviroment.
Disable limit param in GET /allocation_candidates if force_hosts
or force_nodes is set.
Change-Id: Iff1b49fe7e6347e3c2bb5992494b2450809719a2
Closes-Bug: #1777591
This uses the destination host port binding information to plug
vifs on the destination host during pre_live_migration.
This gets "turned on" later in the series when conductor sets the
migrate_data.vifs field.
Part of blueprint neutron-new-port-binding-api
Change-Id: Ia803978401a0a9e8e28af006ffda1f4897ecd9f0
The pre_live_migration() method is already large so this
factors out the plug_vifs() call into a separate method
since we're going to build on it in an upcoming patch.
Part of blueprint neutron-new-port-binding-api
Change-Id: Iad4edecee9866d4eadd9da2d81b6fba214578c91
This adds a simple helper function to VIFMigrateData to
get a destination VIF object based on the set source_vif
but updated with destination port binding details. This
will be used by the libvirt driver in later patches in
the series.
Part of blueprint neutron-new-port-binding-api
Change-Id: I4c5b1fee4a4f6b6ab7b0b1bb2c1049e23a981b48
- This change adds a new VIFMigrateData object.
- This change adds a new vifs field to the
base LiveMigrateData object.
Later patches will populate this information during
live migration where nova uses the neutron port
binding extended API to bind the port on the destination
host, and store the destination host binding details
in this object to be leveraged on the source host for
things like defining vif details in the guest before
starting the live migration in the hypervisor.
Note that vif_details and profile must be stored as
serialized dicts similar to
LibvirtLiveMigrateBDMInfo.connection_info_json.
Co-Authored-By: Matt Riedemann <mriedem.os@gmail.com>
Part of blueprint neutron-new-port-binding-api
Change-Id: I174ae21f143016bb23b8043fa22465dac6c71314
Zuul