[openstack-dev] [nova] Supporting force live-migrate and force evacuate with nested allocations
jaypipes at gmail.com
Wed Oct 10 12:42:46 UTC 2018
On 10/09/2018 05:01 PM, Eric Fried 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 means
>>> (at least to me) that you should not change the behavior of the force
>>> 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 GET
>> /a_c, followed by a claim_resources() on the destination host.
>> For the old microversion behaviour, continue to do the "blind copy" of
>> allocations from the source compute node provider to the destination
>> compute node provider.
> TBC, for nested/sharing source, we should consolidate all the resources
> into a single allocation against the destination's root provider?
No. If there's >1 provider in the allocation for the source, just fail.
>> That "blind copy" will still fail if there isn't
>> capacity for the new allocations on the destination host anyway, because
>> the blind copy is just issuing a POST /allocations, and that code path
>> 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 around
> to restore? Cause we can't re-figure it from the now-monolithic
> destination allocation.
Again, just hard fail if there's >1 provider in the allocation on the
>> 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)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev