Open Stack

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 
>>> means
>>>  (at least to me) that you should not change the behavior of the 
>>> force
>>>  flag in the old microversions.
>> 
>>  Agreed.
>> 
>>  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?

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 
destination host.

> 
>>  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.

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.

Cheers,
gibi

> 
>>  There isn't a
>>  code path in the placement API that allows a provider's inventory
>>  capacity to be exceeded by new allocations.
>> 
>>  Best,
>>  -jay
>> 
>>  
>> __________________________________________________________________________
>>  OpenStack Development Mailing List (not for usage questions)
>>  Unsubscribe: 
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev