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 <rakhme...@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 <d...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Davanum Srinivas :: https://twitter.com/dims
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev