On 22/09/14 10:40, Geoff O'Callaghan wrote:
So
On 22/09/2014 10:01 PM, "Zane Bitter" <zbit...@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.
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
