Open Stack

On 01/23/2013 11:34 PM, Caitlin Bestler wrote:
> Gary Kotton [mailto:gkotton at redhat.com] wrote:
>
> Hi,
>> The link https://docs.google.com/document/d/1bAMtkaIFn4ZSMqqsXjs_riXofuRvApa--qo4UTwsmhw/edit introduces the concept
>> of a VM ensemble or VM group into Nova. An ensemble will provide the tenant the ability to group together VMs that provide a
>> certain service or part of the same application. More specifically it enables configuring scheduling policies per group. This will in turn
>> allow for a more robust and resilient service. Specifically, it will allow a tenant to deploy a multi-VM application that is designed for
>> VM fault tolerance in a way that application availability is actually resilient to physical host failure.
>> Any inputs and comments will be greatly appreciated.
> This involves concepts that want to be at different layers.
>
> An ensemble is most naturally a template that can be applied to multiple instances to create related sets of VMs.
> When viewed as a repeatable macro, you would want this to be implemented very high in the stack.

I agree with you. But we need to be able to ensure that the defined 
group can be deployed correctly. The only way that that can be done is 
if the scheduler has a complete picture of the instances that are to be 
deployed.

>
> But there is the aspect that your doc focuses on which is the low level impact on scheduling.
> Perhaps we need a high layer template that can turn into instance-specific scheduling hints?

The scheduling hints do not enable the scheduler to see the entire 
picture and can cause problematic placements (as described in the 
document). In order  for the scheduler to provide the optimal placements 
it needs to see the entire picture.

The goal here is to provide the scheduler with the relevant information 
so that it can do its magic.

>
> Of more specific interest, I would like to suggest that "group" mechanisms specifically include
> the ability to support multi-session servers within these groups.
>
> For example, the database backends. Rather than launching a VM for each backend it might
> make more sense to just launch a VNIC on an existing server to create support for a specific
> set of VMs.
>
> If you are replicating a pattern of servers on a per tenant basis it would be nice to be able to
> express that pattern without requiring a per-tenant VM just to isolate the service. Isolating
> a VNIC is sufficient.

These are nice ideas and are well worth discussing.


>