Open Stack

On 22/09/14 10:40, Geoff O'Callaghan wrote:
> So
> On 22/09/2014 10:01 PM, "Zane Bitter" <zbitter at redhat.com> wrote:
>>
>> On 20/09/14 04:17, Geoff O'Callaghan wrote:
>>>
>>> Hi all,
>>> I'm just trying to understand the messaging strategy in openstack.    It
>>> seems we have at least 2 messaging layers.
>>>
>>> Oslo.messaging and zaqar,  Can someone explain to me why there are two?
>>>
>>> Is there a plan to consolidate?
>>
>>
>> I'm trying to understand the database strategy in OpenStack. It seems we
> have at least 2 database layers - sqlalchemy and Trove.
>>
>> Can anyone explain to me why there are two?
>>
>>
>> Is there a plan to consolidate?
>> </sarcasm>
>>
>
> So the answer is because we can ;)  Not a great answer, but an answer
> nonetheless.  :)

No, the answer is that they're completely different things :)

> That being said I'm not sure why a well constructed zaqar with an rpc
> interface couldn't meet the requirements of oslo.messsaging and much
> more.    It seems I need to dig some more.

Usually when people talk about "consolidation" they mean "why isn't 
Zaqar just a front-end to oslo.messaging?". If you mean that there 
should be a Zaqar back-end to oslo.messaging (alongside the existing 
AMQP and ZeroMQ back-ends) then that is a stronger possibility. (In my 
increasingly tortured analogy I guess this would be equivalent to using 
Trove in the undercloud to provision the RDBMS for other OpenStack 
services, which is a perfectly respectable idea).

That said, I'm not sure if the semantics fit. Most uses of 
oslo.messaging AFAIK are RPC-style calls (I'm not sure what the 
percentage breakdown of call vs. cast is, but I believe it's heavily 
weighted in favour of the former). So basically it's mostly used for 
synchronous stuff. To me, the big selling point of Zaqar is (or at least 
IMHO should be - see discussion in other thread) that it is end-to-end 
reliable even for completely asynchronous delivery. If that's not a 
requirement for OpenStack services then the stuff Zaqar does to achieve 
it (writing each message to multiple disks in a cluster before 
delivering it) is probably wasted overhead for this particular application.

tl;dr it's possible but probably inefficient due to differing requirements.

cheers,
Zane.