[openstack-dev] [Nova] virt driver architecture

Russell Bryant rbryant at redhat.com
Thu May 9 15:39:24 UTC 2013


On 05/09/2013 11:16 AM, Dan Smith wrote:
>> Punting off to yet another management system that wants to manage all
>> of the same things as OpenStack seems like a broken architecture. 
> 
> Yeah, agreed. I worry that much of this stems from a desire to have an
> OpenStack API in front of these other systems. If that's the case, it
> seems like there are better (simpler) ways to go about that than
> trying to make all of Nova's layers aware/tolerant of the features of
> said systems. If those systems can consume and share resources like
> Glance and Quantum, then maybe they don't need to actually sit
> underneath nova-api, nova-compute, etc?
> 
>> 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.
> 
> 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.
> 
> 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?

This cells idea is quite clever.  I think it makes a lot of sense
architecturally.

I think it's also a ton of work to get there.  That doesn't mean it's
bad or the wrong long term direction, though.  We should keep thinking
about this idea, for sure.

-- 
Russell Bryant



More information about the OpenStack-dev mailing list