[openstack-dev] [requirements] [global-requirements] [mistral] Using pika library

Renat Akhmerov rakhmerov at mirantis.com
Mon Aug 24 13:03:51 UTC 2015


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


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

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

Thanks

Renat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150824/3f63e3bb/attachment.html>


More information about the OpenStack-dev mailing list