> FWIW, I don't have a problem with the virt driver "knowing about > allocations". What I have a problem with is the virt driver *claiming > resources for an instance*.
+1000. > That's what the whole placement claims resources things was all about, > and I'm not interested in stepping back to the days of long racy claim > operations by having the compute nodes be responsible for claiming > resources. > > That said, once the consumer generation microversion lands [1], it > should be possible to *safely* modify an allocation set for a consumer > (instance) and move allocation records for an instance from one > provider to another. Agreed. I'm hesitant to have the compute nodes arguing with the scheduler even to patch things up, given the mess we just cleaned up. The thing that I think makes this okay is that one compute node cleaning/pivoting allocations for instances isn't going to be fighting anything else whilst doing it. Migrations and new instance builds where the source/destination or scheduler/compute aren't clear who owns the allocation is a problem. That said, we need to make sure we can handle the case where an instance is in resize_confirm state across a boundary where we go from non-NRP to NRP. It *should* be okay for the compute to handle this by updating the instance's allocation held by the migration instead of the instance itself, if the compute determines that it is the source. --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