Open Stack

On May 9, 2013, at 9:30 AM, Devananda van der Veen <devananda.vdv at gmail.com> wrote:

> On Thu, May 9, 2013 at 8:45 AM, Sean Dague <sean at dague.net> wrote:
> 
> I think we learned a really important lesson in baremetal: putting a different complex management system underneath the virt driver interface is a bad fit, requires nova to do unnatural things, and just doesn't make anyone happy at the end of the day. That's since resulted in baremetal spinning out to a new incubated project, Ironic, which I think is really the right long term approach.
> 
> I think we need to take that lesson for what it was, and realize these virt cluster drivers are very much the same kind of problem. They are better served living in some new incubated effort instead of force fitting into the nova-compute virt layer and driving a lot more complexity into nova.
> 
> I don't feel like a new project is needed here -- the ongoing discussion about moving scheduling/orchestration logic out of nova-compute and into conductor-or-something-else seems to frame this discussion, too. 
> 
> The biggest change to Nova that I recall around adding the Baremetal code was the addition of the "node" aka "hypervisor_hostname" concept -- that a single nova compute host might control more than one discrete thing, which thereby need to be identified as (host, node). That change opened the door for other cluster drivers to fit under the virt interface. IMBW, but I believe this is exactly what the vCenter and Hyper-V folks are looking at. It's also my current plan for Ironic. However, I also believe that this logic doesn't necessarily have to live under the virt API layer; I think it's a really good fit for the orchestration/conductor discussions....
> 
> We were talking about this a few days ago in -nova, particularly how moving some of the ComputeManager logic out to conductor might fit together with simplifying the (host, node) complexities, and help make nova-compute just a thin virt API layer. Here is a very poor summary of what I recall...
> * AMQP topic is based on "nodename", not "hostname"
> * for local hypervisors (KVM, etc), the topic identifies the local host, and the local nova-compute agent subscribes to it
> * for clustered hypervisors (ironic, vCenter, etc), the topic identifies the unique resource, and any nova-compute which can manage that resource subscribes to the topic.

I wonder if this is a different discussion than the one I was involved in recently.  The one I was involved with was more:

1) AMQP topic is still based on 'hostname'
2) instance['host'] goes away, though.  We're left with only instance['node']
3) All concepts of scheduling/resource tracking for host and node is now just for the 'node'.
4) In order to do an action (build, or otherwise) on a node, you have some sort of mapping of node -> host, so you can cast to the correct nova-compute.  Ie, topic=instance['host'] becomes:  topic=topic_for_node(instance['node']) where we've not exactly defined how topic_for_node() works yet. :)

(Or in the case of Ironic, #4 might be that we talk to Ironic API and there's no need for a nova-compute at all? -- I don't have a full picture of how Ironic will tie in completely, yet.)

But the ideas above are pretty close, it sounds like.

> This would also remove the SPoF that nova-compute currently has for any cluster-of-discrete-things it manages today (eg, bare metal).

Yeah, that's part of the idea with moving things to conductor.

- Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130509/38a10621/attachment.html>