[openstack-dev] [mistral][oslo.messaging] stable/mitaka is broken by oslo.messaging 5.0.0

Mehdi Abaakouk sileht at sileht.net
Wed May 18 06:31:35 UTC 2016


On Tue, May 17, 2016 at 09:41:11PM -0700, Joshua Harlow wrote:
>Doug Hellmann wrote:
>
>So there are a few options I am seeing so far (there might be more 
>that I don't see also), others can hopefully correct me if they are 
>wrong (which they might be) ;)
>
>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).

This is still my favorite option.

>Option #2
>
>Oslo.messaging (and the dispatcher part that does this) changes 
>(possibly allowing it to be replaced with a different type of 
>dispatcher, ie like in https://review.openstack.org/#/c/314732/); the 
>default class continues being great at 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. If people want to provide an 
>alternate class with different semantics they are somewhat on there 
>own (but at least they can do this).
>
>Issues raised: this though may not be wanted, as some of the 
>oslo.messaging folks do not want the dispatcher class to be exposed at 
>all (and would prefer to make it totally private, so exposing it would 
>be against that goal); though people are already 'hacking' this kind 
>of functionality in, so it might be the best we can get at the current 
>time?

Exposing dispatcher will not fix the mistral issue, because since
oslo.msg 5.0, dispatcher does not talk directly to the driver interface
anymore (that was a design issue). All drivers interactions have been
moved into RPCServer and NotificationListener where stuffs are already
private since the beginning. Thanks to Dmitriy Ukhlov, for its amazing
work on this (The server/executor/dispatcher refactoring was a huge
simplication of oslo.messaging internal).

>Option #3
>
>Do nothing.
>
>Issues raised: everytime oslo.messaging changes this *mostly* internal 
>dispatcher API a project will have to make a new 'hack' to replace it 
>and hope that the semantics that it has 'hacked' in will continue to 
>be compatible with the various drivers in oslo.messaging. Not IMHO a 
>sustainable way to keep on working (and I'd be wary of doing this in a 
>project if I was the owner of one, because it's ummm, 'dirty').

Mistral have removed its hack since we break them with oslo.messaging
5.0.0


Cheers,
-- 
Mehdi Abaakouk
mail: sileht at sileht.net
irc: sileht



More information about the OpenStack-dev mailing list