Open Stack

On May 9, 2013, at 8:16 AM, Dan Smith <dms at danplanet.com> wrote:
[…]
>> We now have two different types of drivers: those that manage
>> individual hypervisor nodes, and those that proxy to much more
>> complex systems.
> 
> I really suspect that consuming a complex system like vCenter at the
> virt layer is the wrong approach and likely to quickly become a mess of
> trying to push features of these less-cloudy systems up several layers
> in the stack so they are exposed to the user. I think we learned that
> lesson with the baremetal stuff.

I disagree with creating a virt driver that operates such that 1 compute node manages greater than 1 hypervisor node.  I think it unnecessarily complicates things.  I'd really like to ditch the (host, node) stuff for this reason.  (Devananda touched on this in a reply and I'll comment further there.)  If there's still a 1<->1 mapping, I think I'm *mostly* okay.  And I think for some of these 'more complex' systems you can use them in either way.  I believe the XenAPI code can be used with xenserver/xcp pools, for example.  But I think we still direct builds to specific hypervisors, so it's not extremely complicated.

> 
> Another approach I've thought about is to consume these large systems
> at the cells layer. Right now, I think a vCenter or oVirt deployment
> looks a lot like a child cell in Nova, in that it implements a
> scheduler, provides compute nodes, and (presumably) consumes services
> from Glance, Quantum, etc. If (yes, it's a big "if") the cells interface
> was codified in such a way that other things could implement it, then we
> could presumably have aggregation of Nova compute resources with
> vCenter resources as children under a single parent API cell.

Yes, I think this makes a lot of sense.  At some point we need to come back around to bursting.  One big thing we want to get to is being able to burst from OS cloud to another OS cloud.  I haven't spent a lot of time thinking about it, but it feels like something that is done at a cell level.  And with these other 'complex systems' like vSphere and whatever that manage their own pools of resources, you can think of them in the context of bursting as well.  It's just that, instead, we're bursting from OS to vSphere, etc.

> 
> Doing this would achieve the goal of a single API for both, yet avoid
> tight integration between nova-compute and its virt driver layer. Since
> things like (for example) migration are already provided by these other
> complex systems, why place them underneath other implementations like
> nova-compute's migration which expects to orchestrate things at a much
> lower level?

Another thought I had was that as we move more things to conductor, conductor could become the place to plug in the more complex systems.  But the cells idea maybe makes more sense.

- Chris