Open Stack

On 05/10/2013 02:57 AM, Dan Wendlandt wrote:
> 
> 
> 
> On Thu, May 9, 2013 at 1:29 PM, Chris Behrens <cbehrens at codestud.com
> <mailto:cbehrens at codestud.com>> wrote:
> 
> 
>     On May 9, 2013, at 8:16 AM, Dan Smith <dms at danplanet.com
>     <mailto: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. 
> 
> 
> Just trying to make sure I understand the concerns, as I think this is a
> really important point.  Is the concern around the fact that one
> nova-compute ends up controlling multiple physical devices, or that one
> nova-compute ends up corresponding to multiple "hosts" in terms of state
> that Nova tracks, can scheduler over, etc.  If I'm understanding this
> thread correctly, it seems like the concerns are mostly around the
> latter.  If a particular back-end technology happens to make several
> hypervisors look like one big hypervisor but nova just treats it as one
> big hypervisor, I wouldn't expect that this would cause concern.  

It's more of the latter.  In general it's a concern that we're using a
single interface for two very different types of interfacing.  We need
to figure out if there's a *better* place to plug in for proxying to
other complex systems as opposed to managing hypervisor nodes.

> I think the suggestion around cells is pretty clever, though I'd have to
> do more reading on the cells API in general to fully understand the
> implications.  I completely buy that the existing virt interface was
> designed for "per-host" management (hence the tight coupling of
> resources + the message bus topology) and thus there may be a better way
> to plug in "proxy" systems in Nova.  

Definitely take a look at cells, but I don't think the concept we're
discussing is trivial right now.  Plugging in things at this layer is an
architectural concept, not something you could easily do right now.  It
really does feel like the right way to go, though.

> Clearly one reason the "proxy"
> systems are integrating with Nova is a desire from OpenStack users to
> control those systems via the OpenStack Compute API (and possibly the
> EC2-compat API as well, I guess).  It sounds like the cells approach
> would enable that?  

If all people really want is to add OpenStack API support to an existing
system, then I think all of this is definitely the wrong way to do it.
Just adding the API to your existing system, or using an API proxy
project like DeltaCloud makes *WAY* more sense to me.

> But I think another key reason is to gain some of
> the flexibility in scheduling and placement, including pluggable
> scheduling algorithms and concepts like host-aggregates, availability
> zones, etc.  I'm less clear on whether cells would enable that (seems
> like some comments imply it would not?).  

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.

-- 
Russell Bryant