> 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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
