On Tue, Oct 9, 2018 at 11:01 PM, Eric Fried <openst...@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-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
