Open Stack

> On 24 Aug 2015, at 20:17, Doug Hellmann <doug at doughellmann.com> wrote:
>> My point is the following: we’re not getting rid of oslo.messaging for several reasons (community standard,
>> its developers have better vision and expertise at messaging etc.). In any case we’ll have oslo.messaging as one of our 
>> implementations for rpc layer (by it I mean very Mistral specific interface to distribute tasks over executors and similar).
>> And we’re, of course, ready to further work with you on evolving oslo.messaging in the right direction.
>> At the same time we still have an idea of implementing our RPC alternatively (w/o oslo.messaging) just for
>> purely time reasons, in other words, we want to have that missing feature as soon as possible because our
>> customers are already using Mistral in production and it affects them. But once we got all needed in oslo.messaging
>> we can get rid of our own implementation at all.
> 
> Except you'll need to maintain support for the configuration options
> you'll have to add in order to use pika for at least 2 cycles, which
> means you're stuck maintaining that stuff for a year. I think it will
> take much less time than that to add the feature you want to
> oslo.messaging.

We don’t have to use pika, it’s just a preference. Kombu is eventually ok too. I rather meant non-oslo.messaging implementation of RPC.

>> Changing semantics seemed to be exactly the main challenge we had in mind.
>> It made us think it would hardly be implemented within oslo.messaging any time soon.
>> If you’re saying it’s not impossible then it’s good, we need to discuss how it may be
>> implemented in a backwards compatible manner.
> 
> The only reason this would be hard is if you expect every other user of
> oslo.messaging to decide to adopt the same semantics you want at the
> same time. If we build a flag into the API, in a backwards-compatible
> way, all we have to do is update the library itself.

Ok, got your point. We need to see more detailed if it works out.

>> 
>>> However we implement it, we need to ensure backwards compatibility
>>> for applications relying on the current behavior. For example,
>>> perhaps the application would pass a flag to the messaging library
>>> to control whether ACKs are sent before or after processing (we
>>> don't want that as a configuration option, because it's the application
>>> developer who needs to handle any differences in behavior, rather
>>> than the deployer). We should start out with the default behavior
>>> set to what we have now, and then we can experiment with changing
>>> it in each application before changing the default in the library.
>>> 
>>> So, if you're interested in working with us on that, let us know.
>> 
>> Yes, we are. What would be the next practical steps that you could suggest?
> 
> Dims proposed a spec, and I think in this case that's a good idea so we
> can ensure we understand how the change will affect drivers other than
> rabbit. It may be OK to start out by saying that the other drivers will
> (or may) ignore the flag, especially since it may not make any sense for
> something like zmq at all.

Ok, thanks.


Renat