[openstack-dev] [nova] Supporting force live-migrate and force evacuate with nested allocations
balazs.gibizer at ericsson.com
Wed Oct 10 09:04:22 UTC 2018
On Tue, Oct 9, 2018 at 11:01 PM, Eric Fried <openstack at fried.cc> wrote:
> On 10/09/2018 02:20 PM, Jay Pipes wrote:
>> On 10/09/2018 11:04 AM, Balázs Gibizer wrote:
>>> If you do the force flag removal in a nw microversion that also
>>> (at least to me) that you should not change the behavior of the
>>> flag in the old microversions.
>> Keep the old, buggy and unsafe behaviour for the old microversion
>> and in
>> a new microversion remove the --force flag entirely and always call
>> /a_c, followed by a claim_resources() on the destination host.
>> For the old microversion behaviour, continue to do the "blind copy"
>> allocations from the source compute node provider to the destination
>> compute node provider.
> TBC, for nested/sharing source, we should consolidate all the
> into a single allocation against the destination's root provider?
Yes, we need to do that not to miss resources allocated from a child RP
on the source host and succeed without a complete allocation on the
>> That "blind copy" will still fail if there isn't
>> capacity for the new allocations on the destination host anyway,
>> the blind copy is just issuing a POST /allocations, and that code
>> still checks capacity on the target resource providers.
> What happens when the migration fails, either because of that POST
> /allocations, or afterwards? Do we still have the old allocation
> to restore? Cause we can't re-figure it from the now-monolithic
> destination allocation.
For live-migrate we have the source allocation held by the
migration_uuid so we can simply move that back to the instance_uuid
when the allocation fails on the destination host.
For evacuate the source host allocaton is also held by the
instance_uuid (no migration_uuid is used) but it is not a real problem
here as nova failed to change that allocation so the original source
allocation is intact in placement.
>> There isn't a
>> code path in the placement API that allows a provider's inventory
>> capacity to be exceeded by new allocations.
>> OpenStack Development Mailing List (not for usage questions)
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> OpenStack Development Mailing List (not for usage questions)
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev