> This would be a very interesting direction to explore. Focus on the pain > points of the message queue and then look at addressing the beast that > is the database layer separately. I am going to toss support in behind a > lot of what has been said in this thread already. But I really wanted to > voice my support for exploring this option if/when we have a bit of > time. Not fragmenting the DB unless it's really needed, is a good approach. > > With that all said... I wouldn't want to derail work simply because of a > "nice to have" option.
There's really no derailing necessary. The point of cells is to partition those things and there's no reason I can foresee that keeping the database bits together shouldn't work if you deploy it that way. The DB and MQ partitioning are really pretty separate things. If everything works the way it should, you should be able to do the opposite as well: keep the DB separate and the MQ unified. I don't know why you'd want to do that, other than "to piss off Monty". So, hmm, maybe some value there actually.. :P --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
