Open Stack

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?