On 09/10/2014 04:16 PM, Russell Bryant wrote:
On Sep 10, 2014, at 2:03 PM, Joe Cropper <[email protected]>
wrote:
I would like to craft up a blueprint proposal for Kilo to add two
simple extensions to the existing server group APIs that I believe
will make them infinitely more usable in any ‘real world’ scenario.
I’ll put more details in the proposal, but in a nutshell:
1. Adding a VM to a server group Only allow it to succeed if its
policy wouldn’t be violated by the addition of the VM
I'm not sure that determining this at the time of the API request is
possible due to the parallel and async nature of the system. I'd love
to hear ideas on how you think this might be done, but I'm really not
optimistic and would rather just not go down this road.
I can see a possible race against another instance booting into the
group, or another already-running instance being added to the group. I
think the solution is to do the update as an atomic database transaction.
It seems like it should be possible to create a database operation that
does the following in a single transaction:
--look up the hosts for the instances in the group
--check that the scheduler policy would be satisfied (at least for the
basic affinity/anti-affinity policies)
--add the instance to the group
Chris
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
