Open Stack

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?

And remove would be fairly straightforward as well since no constraints would need to be checked. 

Thoughts?

Thanks,
Joe

> On Aug 25, 2014, at 12:10 PM, Russell Bryant <rbryant at redhat.com> wrote:
> 
>> On 08/25/2014 12:56 PM, Joe Cropper wrote:
>> That was indeed a rather long (and insightful) thread on the topic.
>> It sounds like there are still some healthy discussions worth having
>> on the subject -- either exploring your [potentially superseding]
>> proposal, or minimally rounding out the existing server group API to
>> support "add existing VM" [1] and "remove VM" -- I think these would
>> make it a lot more usable (I'm thinking of the poor cloud
>> administrator that makes a mistake when they boot an instance and
>> either forgets to put it in a group or puts it in the wrong group --
>> it's square 1 for them)?
>> 
>> Is this queued up as a discussion point for Paris?  If so, count me in!
> 
> Adding a VM is far from trivial and is why we ripped it out before
> merging.  That implies a potential reshuffling of a bunch of existing
> VMs.  Consider an affinity group of instances A and B and then you add
> running instance C to that group.  What do you expect to happen?  Live
> migrate C to the host running A and B?  What if there isn't room?
> Reschedule all 3 to find a host and live migrate all of them?  This kind
> of orchestration is a good bit outside of the scope of what's done
> inside of Nova today.
> 
> -- 
> Russell Bryant
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev