Open Stack

+1, Chris.

I think the key thing here is that such race conditions can already happen if timed just right, unless there’s been some additional checks put in place in the compute API layer since I last scanned the code.  We could even look at some x-process locking mechanisms as well if we think that’s necessary.

Overall, this seems like a feasible, fairly minor enhancement--that wouldn’t make us any worse off than we are today (perhaps address some existing race conditions), all whilst providing a large improvement to the overall usability of the server groups.  :-)

- Joe
On Sep 10, 2014, at 5:54 PM, Chris Friesen <chris.friesen at windriver.com> wrote:

> On 09/10/2014 04:16 PM, Russell Bryant wrote:
>> 
>> 
>>> On Sep 10, 2014, at 2:03 PM, Joe Cropper <cropper.joe at gmail.com>
>>> 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
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev