Open Stack

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

--Dan