Open Stack

On Tue, Jan 08, 2013 at 07:00:17PM +0000, JC Martin wrote:
> Gary,
> 
> This is a very interesting feature. I have a question on where the definition of ensembles will reside. It seems from the linked document that the definition of ensemble membership will only reside in Heat.
> However, I would think that generic grouping capabilities in Nova would be useful (e.g. to boot a group of VM). I can see that many of such group operations might require the type of scheduling that is available in Heat, but I would prefer that the basic notion of VM group be implemented in Nova, with the right scheduling support, so that it can be available without having Heat deployed and can also be exposed in Horizon more easily.

I agree - I like the idea of group scheduling in nova, and I also like the
idea of being able to specify anti-affinity for potential resiliency to host
failures.

However I do not like the scheduler->heat "callback" topology proposed in
this document, I think it introduces unneccesary additional complexity and
coupling between the two services.

I think it would be better if all the required information could be passed
to the scheduler via the nova API at instance-group-launch time, then either
heat, or any other user of the nova API could gain access to this
functionality.

It seems to me that most of what you propose could be achived with the
addition of "instance groups" to nova, combined with some new scheduler
hints which allow you to specify instance anti-affinity for hosts,
host-aggregates or availability zones.

-- 
Steve Hardy
Red Hat Engineering, Cloud