On 04/22/2016 05:29 PM, Dan Smith wrote:
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
You're telling me there were other reasons other things were done around
here?
__________________________________________________________________________
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
