Open Stack

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

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

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