On Wed, 18 May 2016 08:51:00 -0700 Joshua Harlow <[email protected]> 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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
