Open Stack

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

Yes. The parent cell has the externally-facing nova-api node which is
the "value" to these other systems. Requests are sent down to the child
cell to handle somewhat autonomously.

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

If I understand your question correctly, it would, and that's precisely
the point, I think. These other systems have different goals in their
scheduling and placement, often making decisions to migrate workloads
for load balancing or automatic fault avoidance. By letting them expose
that at the compute level instead of the virt level, they can avoid the
need to drive awareness of these operations (both configuration and
potentially notification after a change) into nova-compute itself.
Since we're trying to whittle nova-compute down to the smallest
reasonable amount of function with as little state as possible, this
helps avoid a conflict between the two goals.

--Dan