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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
