Open Stack

> On Monday, May 13, 2013 10:28 PM, Dan Wendlandt wrote:
> 
> They way I see it, there are two extremes:
> 1) The current virt-driver approach, with one nova-compute per per
> "host", where "host" is a single unit of capacity in terms of
> scheduling, etc.  In KVM-world a "host" is a hypervisor node.  In
> current vCenter driver, this is a cluster, with vCenter exposing one
> large capacity and spreading workloads evenly.  This approach leverages
> all scheduling logic available within nova.scheduler, uses nova DB
> model, etc.
> 2) A true "API proxy" approach, possibly implemented using cells.  All
> scheduling/placement, data modeling, etc. logic would be implemented by
> a back-end system such as vCenter and one cannot leverage existing nova
> scheduler logic or database models.   I think this would mean that the
> nova-api, nova-scheduler, and nova-compute code used with the virt-
> driver model would not be used, and the new cell driver would have to
> create its own versions of this.
> 
> However, what is being proposed in the blueprint is actually something
> in between these two extremes and in fact closer to the virt-driver
> model.  I suspect the proposal sees the following benefits to a model
> that is closer to the existing virt-driver (note: I am not working
> closely with the author, so I am guessing here based on my own views):
> -  the nova scheduler logic is actually very beneficial even when you
> are using something like vCenter.  It lets you do a  KVM + vmware
> deployment, where workloads are directed to vmware vs. KVM by the
> scheduler based on disk type, host aggregates, etc.  It also lets you
> expose different vCenter clusters with different properties via host
> aggregates (e.g., an HA cluster and a non-HA cluster).  


The main intent is to leverage the capabilities/features natively offered by the cluster without changing any O~S constructs. As Dan pointed out, the host aggregates allows more flexibility in consuming cluster features. The cluster specific features are not pushed onto other components such as scheduler. 



> According to
> the docs I've read on cells (may be out of date), it seems like the
> current cell scheduler is very simple (i.e., random), so doing this
> with cells would require adding similar intelligence at the cell
> scheduler layer.   Additionally, I'm aware of people who would like to
> use nova's pluggable scheduling to even do fine-grain per-hypervisor
> scheduling on a "cluster" platform like vCenter (which for a cluster
> with DRS enabled would make sense).
> - there is a lot of nova code used in the virt-driver model that is
> still needed when implementing Nova with a system like vCenter.  This
> isn't just the API WSGI + scheduling logic, it includes code to talk to
> quantum, glance, cinder, etc.  There is also data modeled in  the Nova
> DB that is likely not modeled in the back-end system.  Perhaps with
> significant refactoring this shared functionality could be put in
> proper libraries that could be re-used in cells of different types, but
> my guess is that it would be a significant shake-up of the Nova
> codebase.
> 
> As I read the blueprint, it seems like the idea is to make some more
> targeted changes.  In particular:
> 1) remove the hard coupling in the scheduler logic between a device
> being scheduler to, and the queue that the scheduling message is placed
> into.
> 2) On the nova-compute side, do not limit a nova-compute to creating a
> single "host" record, but allow it to dynamically update the set of
> available hosts based on its own mechanism for discovering available
> hosts.
> 

Even when a cluster is represented as compute node, it still requires a nova-compute service corresponding to each cluster. This is what is currently supported in Grizzly. To further reduce the number of services required, the blueprint  intends to make a *single* compute service can actually represent each cluster as a compute node, i.e create one compute records one for each cluster. The list of clusters can be specified as a multiStrOpt in the nova.conf. The scheduler is agnostic of the number of services. The scheduler get to view each cluster as compute node and therefore the filters and scheduling will work as it does today with KVM. The number of compute services required is upto the administrator. If there are few clusters to be managed then a single service can be configured. If the number of cluster increases, to handle scale, more services can be created and each service managing (making available cluster as compute-node) a set of clusters.


Thanks,
Kiran