Open Stack

On 01/10/2013 02:17 PM, Steven Hardy wrote:
> 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.

In the document there were two proposals. One is an option of having 
Nova receive an ensemble as input. I think that following all of the 
comments on the thread that this is where we should start.

>
> 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.
>