Open Stack

Renat,

Please file a blueprint to discuss the problem and options against
oslo-specs repository so we can get a headstart before the Tokyo summit.

thanks,
dims

On Mon, Aug 24, 2015 at 9:03 AM, Renat Akhmerov <rakhmerov at mirantis.com>
wrote:

> (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> 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
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Davanum Srinivas :: https://twitter.com/dims
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150824/66ef4379/attachment.html>