> On Sep 10, 2014, at 2:03 PM, Joe Cropper <cropper....@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.frie...@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@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to