Open Stack

Excerpts from Renat Akhmerov's message of 2015-08-24 19:03:51 +0600:
> (Resending the email that I sent last week but it doesn’t seem to have been sent out actually…)
> 
> > On 19 Aug 2015, at 21:44, Doug Hellmann <doug at doughellmann.com <mailto:doug at doughellmann.com>> wrote:
> > 
> > Excerpts from Nikolay Makhotkin's message of 2015-08-19 17:16:14 +0300:
> >> Hi, Davanum!
> >> 
> >> Have you already read the thread [1]? It is about acknowledge feature in
> >> oslo.messaging. Particularly, about the absent of this feature in
> >> oslo.messaging.
> >> 
> >> The guys from messaging said that it is very problematically to add that
> >> kind of feature to oslo.messaging because it does not fit to
> >> oslo.messaging's approach.
> > 
> > The Oslo libraries are meant to evolve as the needs to the applications
> > evolve. That process works best when it comes about through
> > collaboration between all of us, and the Oslo team has taken on the
> > mission of enabling that collaboration. What I'm hearing in this
> > request is "the library our community has written doesn't do something
> > we want, so rather than work on it with other members of our community
> > we want to adopt a different library that is missing different
> > features" [2].
> 
> Doug, yes, I agree. That’s why we decided to start the thread that Nikolay pointed to. To collaborate on that.
> 
> 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.

> 
> > As far as I can tell from reading the thread you linked to, you
> > weren't told "no" just that it might be harder than just moving the
> > place we send acknowledgments inside the current driver, and we're
> > likely to need your help with the implementation.  The thread sort
> > of died off, so perhaps that wasn't clear.
> 
> We can try to help with this.
> 
> > You have what seems to be a new case -- perhaps its an old case
> > that was never being handled properly and everyone actually always
> > wanted this, I don't know. Either way, handling that case will
> > require a change to the semantics of the library, which means we
> > need to be careful about how we do it, but it's not impossible or
> > unwanted.
> 
> 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.

> 
> > 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.

Doug

> 
> Thanks
> 
> Renat