Open Stack

On Fri May 10 13:42:40 UTC 2013, , Russell Bryant wrote:
> 
> The cells concept would leave most of that to the system we're
> delegating to.  In the cells world, scheduling happens in two stages.
> The first stage is cell scheduling; which cell should run this
> instance?
>  The second stage is host scheduling (the traditional nova-scheduler),
> which happens within the cell.  If you plugged in at the cells layer,
> deciding which cluster/host/whatever is left up to the system we're
> delegating to.
> 
> I guess a lot of this comes down to division of responsibilities.  We
> need to be clear about what we intend nova to be responsible for.  Is
> it
> responsible for individual hosts?  If so, the virt layer makes sense.
> If it's something more high level than that, I think we're better off
> not trying to use all of the existing infrastructure built around
> single-host management to do so, which is where the cells plugin
> concept
> comes in.
> 

Why can't a cluster be treated an hypervisor compute that has more capacity? This way it still fits into the nova architecture. 
If we were to have each cluster as a separate cell and only have the compute model the individual hypervisor in the cluster, then the nova-scheduler in the (child) cell will interfere with the placement algorithms that the cluster might already have. 
However if you consider having all the clusters in one cell and the cluster is a compute-node then it should be fine. Also, having the cluster treated as another compute (hypervisor with increased capacity and features) will enable easy integration with cinder/glance.

If other capabilities of the management software are pushed up the nova stack, I agree it is a cause of concern, however IMO enabling simple but valuable constructs such as clusters as a nova compute, and have such nova-compute in a different cell should be fine

Thanks,
Kiran