Open Stack

On Thu, May 9, 2013 at 1:29 PM, Chris Behrens <cbehrens at codestud.com> wrote:

>
> 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.


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.

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.  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?  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?).

Thanks,

Dan




 (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
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130509/d690d564/attachment.html>