> On 24 Aug 2015, at 20:17, Doug Hellmann <d...@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 __________________________________________________________________________ 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
