Open Stack

Hmm, not sure I follow the concern, Russell.  How is that any different from putting a VM into the group when it’s booted as is done today?  This simply defers the ‘group insertion time’ to some time after initial the VM’s been spawned, so I’m not sure this creates anymore race conditions than what’s already there [1].

[1] Sure, the to-be-added VM could be in the midst of a migration or something, but that would be pretty simple to check make sure its task state is None or some such.

- Joe
On Sep 10, 2014, at 5:16 PM, Russell Bryant <rbryant at redhat.com> wrote:

> 
> 
>> On Sep 10, 2014, at 2:03 PM, Joe Cropper <cropper.joe at gmail.com> wrote:
>> 
>> I agree, Chris.  I think a number of folks put in a lot of really great work into the existing server groups and there has been a lot of interest on their usage, especially given that the scheduler already has some constructs in place to piggyback on them.
>> 
>> 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. 
> 
>> 2. Removing a VM from a server group
>> Just allow it
>> 
>> I think this would round out the support that’s there and really allow us to capitalize on the hard work everyone’s already put into them.
>> 
>> - Joe
>> 
>>> On Aug 26, 2014, at 6:39 PM, Chris Friesen <chris.friesen at windriver.com> wrote:
>>> 
>>>> On 08/25/2014 11:25 AM, Joe Cropper wrote:
>>>> I was thinking something simple such as only allowing the add
>>>> operation to succeed IFF no policies are found to be in violation...
>>>> and then nova wouldn't need to get into all the complexities you
>>>> mention?
>>> 
>>> Personally I would be in favour of this...nothing fancy, just add it if it already meets all the criteria.  This is basically just a database operation so I would hope we could make it reliable in the face of simultaneous things going on with the instance.
>>> 
>>>> And remove would be fairly straightforward as well since no
>>>> constraints would need to be checked.
>>> 
>>> Agreed.
>>> 
>>> Chris
>>> 
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> 
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140910/7568aca1/attachment-0001.html>