On 10/10/2018 7:46 AM, Jay Pipes wrote:
2) in the old microversions change the blind allocation copy to gather
every resource from a nested source RPs too and try to allocate that
from the destination root RP. In nested allocation cases putting this
allocation to placement will fail and nova will fail the migration /
evacuation. However it will succeed if the server does not need nested
allocation neither on the source nor on the destination host (a.k.a the
legacy case). Or if the server has nested allocation on the source host
but does not need nested allocation on the destination host (for
example the dest host does not have nested RP tree yet).
I disagree on this. I'd rather just do a simple check for >1 provider in
the allocations on the source and if True, fail hard.
The reverse (going from a non-nested source to a nested destination)
will hard fail anyway on the destination because the POST /allocations
won't work due to capacity exceeded (or failure to have any inventory at
all for certain resource classes on the destination's root compute node).
I agree with Jay here. If we know the source has allocations on >1
provider, just fail fast, why even walk the tree and try to claim those
against the destination - the nested providers aren't going to be the
same UUIDs on the destination, *and* trying to squash all of the source
nested allocations into the single destination root provider and hope it
works is super hacky and I don't think we should attempt that. Just fail
if being forced and nested allocations exist on the source.
--
Thanks,
Matt
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
