Open Stack

On Wed, 18 May 2016 08:51:00 -0700
Joshua Harlow <harlowja at fastmail.com> wrote:

> >> Option #1
> >>
> >> Oslo.messaging (and the dispatcher part that does this) stays as is,
> >> doing at-most-once for RPC (notifications are in a different
> >> category here so let's not discuss them) and doing at-most-once well
> >> and battle-hardened (it's current goal) across the various backend
> >> drivers it supports.
> >>
> >> At that point at-least-once will have to done via some other library
> >> where this kind of semantics can be placed, that might be tooz via
> >> https://review.openstack.org/#/c/260246/ (which has similar
> >> semantics, but is not based on a kind of RPC, instead it's more like
> >> a job-queue).

[..]

> > Option #4
> >
> > (Which might be obvious) Directly use RabbitMQ driver, like
> > pika/kombu, which can expose all the message queue features to the
> > project.
> >
> > Issues raised: Pushback from the community due not using
> > oslo.messaging and potential necessity for implementing it for other
> > drivers/transports, or forcing to use particular message queue/driver
> > in every project.
> 
> Isn't this similar/same as to option #1? Nothing about option #1 says 
> (from my understanding) that it must be implemented via oslo.messaging 
> (and in all likely-hood it can't be).

It is similar, but not the same. Using RabbitMQ/pika alone it is fairly
easy to accomplish the goal for using messaging system to wait for the
result. Difference is, there is no external queue involved.

-- 
Cheers,
Roman Dobosz