Open Stack

> However I do want to point out that cells v2 is not just about dealing
> with scale in the database. The message queue is another consideration,
> and as far as I know there is not an analog to the "distributed
> database" option available for the persistence layer.

Yeah, it's actually *mostly* about the messaging layer. In fact, if you
don't want to fragment the database, I'm not sure you have to. Thinking
with my Friday brain, I don't actually think it would be a problem if
you configured all the cells (including the cemetery cell) to use the
same actual database, but different queues. Similarly, you should be
able to merge and split cells pretty easily if it's convenient for
whatever reason.

> Additionally with v1 we found that deployers have enjoyed being able to
> group their hardware with cells. Baremetal goes in this cell, SSD filled
> computes over here, and spinning disks over there. And beyond that
> there's the ability to create a cell, fill it with hardware, and then
> test it without plugging it up to the production API. Cells provides an
> entry point for poking at things that isn't available without it.

People ask me about this all the time. I think it's a bit of a false
impression of what it's for, but the ability to stand up a chunk of new
functionality with a temporary API and then merge it into the larger
deployment is something people seem to like.

--Dan