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