>> 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.
Same, yeah. --Dan __________________________________________________________________________ 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
