<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, May 9, 2013 at 1:29 PM, Chris Behrens <span dir="ltr"><<a href="mailto:cbehrens@codestud.com" target="_blank">cbehrens@codestud.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
On May 9, 2013, at 8:16 AM, Dan Smith <<a href="mailto:dms@danplanet.com">dms@danplanet.com</a>> wrote:<br>
[…]<br>
<div class="im">>> We now have two different types of drivers: those that manage<br>
>> individual hypervisor nodes, and those that proxy to much more<br>
>> complex systems.<br>
><br>
> I really suspect that consuming a complex system like vCenter at the<br>
> virt layer is the wrong approach and likely to quickly become a mess of<br>
> trying to push features of these less-cloudy systems up several layers<br>
> in the stack so they are exposed to the user. I think we learned that<br>
> lesson with the baremetal stuff.<br>
<br>
</div>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. </blockquote>
<div><br></div><div style>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. </div>
<div><br></div><div style>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?). </div>
<div style><br></div><div style>Thanks,</div><div style><br></div><div style>Dan </div><div style><br></div><div style> </div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
(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.</blockquote>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
><br>
> Another approach I've thought about is to consume these large systems<br>
> at the cells layer. Right now, I think a vCenter or oVirt deployment<br>
> looks a lot like a child cell in Nova, in that it implements a<br>
> scheduler, provides compute nodes, and (presumably) consumes services<br>
> from Glance, Quantum, etc. If (yes, it's a big "if") the cells interface<br>
> was codified in such a way that other things could implement it, then we<br>
> could presumably have aggregation of Nova compute resources with<br>
> vCenter resources as children under a single parent API cell.<br>
<br>
</div>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.<br>
<div class="im"><br>
><br>
> Doing this would achieve the goal of a single API for both, yet avoid<br>
> tight integration between nova-compute and its virt driver layer. Since<br>
> things like (for example) migration are already provided by these other<br>
> complex systems, why place them underneath other implementations like<br>
> nova-compute's migration which expects to orchestrate things at a much<br>
> lower level?<br>
<br>
</div>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.<br>
<span class="HOEnZb"><font color="#888888"><br>
- Chris<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>Dan Wendlandt <div>Nicira, Inc: <a href="http://www.nicira.com" target="_blank">www.nicira.com</a><br><div>twitter: danwendlandt<br>
~~~~~~~~~~~~~~~~~~~~~~~~~~~<br></div></div>
</div></div>