*** zaneb has quit IRC | 00:05 | |
*** ianychoi_ has joined #openstack-oslo | 00:18 | |
*** ianychoi has quit IRC | 00:20 | |
*** hberaud|gone has quit IRC | 00:22 | |
*** zzzeek has quit IRC | 00:47 | |
*** zzzeek has joined #openstack-oslo | 00:47 | |
*** bobh has joined #openstack-oslo | 01:26 | |
*** dave-mccowan has quit IRC | 01:34 | |
*** dave-mccowan has joined #openstack-oslo | 01:39 | |
*** zzzeek has quit IRC | 01:57 | |
*** zzzeek has joined #openstack-oslo | 01:58 | |
openstackgerrit | tonybrad proposed openstack/oslo.i18n master: Move to releases.openstack.org https://review.opendev.org/664758 | 02:00 |
---|---|---|
*** zzzeek has quit IRC | 02:13 | |
*** zzzeek has joined #openstack-oslo | 02:16 | |
*** dave-mccowan has quit IRC | 03:46 | |
*** pcaruana has joined #openstack-oslo | 04:54 | |
*** pcaruana has quit IRC | 04:59 | |
*** Luzi has joined #openstack-oslo | 05:22 | |
*** e0ne has joined #openstack-oslo | 05:51 | |
*** e0ne has quit IRC | 06:22 | |
*** takamatsu has quit IRC | 06:46 | |
*** gibi has joined #openstack-oslo | 06:50 | |
*** pcaruana has joined #openstack-oslo | 06:56 | |
*** tesseract has joined #openstack-oslo | 07:14 | |
*** dmellado has quit IRC | 07:17 | |
*** rcernin has quit IRC | 07:22 | |
*** iurygregory has joined #openstack-oslo | 07:26 | |
*** dmellado has joined #openstack-oslo | 07:29 | |
*** takamatsu has joined #openstack-oslo | 07:37 | |
*** ralonsoh has joined #openstack-oslo | 07:42 | |
*** e0ne has joined #openstack-oslo | 07:57 | |
openstackgerrit | Gabriele Santomaggio proposed openstack/oslo.messaging master: Add options parameter https://review.opendev.org/660373 | 08:12 |
*** takamatsu has quit IRC | 08:39 | |
*** takamatsu has joined #openstack-oslo | 08:40 | |
*** jaosorior has quit IRC | 08:51 | |
*** takamatsu has quit IRC | 09:14 | |
*** takamatsu has joined #openstack-oslo | 09:51 | |
*** hberaud has joined #openstack-oslo | 10:03 | |
*** takamatsu has quit IRC | 10:16 | |
*** ansmith_ has joined #openstack-oslo | 10:26 | |
*** ansmith_ has quit IRC | 10:39 | |
*** takamatsu has joined #openstack-oslo | 10:49 | |
openstackgerrit | Adam Spiers proposed openstack/oslo.log master: Fix guidelines w.r.t. translation of log messages https://review.opendev.org/664855 | 10:55 |
openstackgerrit | Adam Spiers proposed openstack/oslo.i18n master: Fix guidelines w.r.t. translation of log messages https://review.opendev.org/664670 | 11:05 |
openstackgerrit | Adam Spiers proposed openstack/oslo.i18n master: Fix guidelines w.r.t. translation of log messages https://review.opendev.org/664670 | 11:17 |
openstackgerrit | Adam Spiers proposed openstack/oslo.i18n master: Clarify that translation strings are extracted via source inspection https://review.opendev.org/664859 | 11:17 |
*** hberaud is now known as hberaud|lunch | 11:35 | |
*** boden has joined #openstack-oslo | 12:02 | |
*** dave-mccowan has joined #openstack-oslo | 12:17 | |
*** hberaud|lunch is now known as hberaud | 12:27 | |
*** raildo has joined #openstack-oslo | 12:28 | |
*** iurygregory has quit IRC | 12:32 | |
*** ansmith_ has joined #openstack-oslo | 12:32 | |
openstackgerrit | Gabriele Santomaggio proposed openstack/oslo.messaging master: Add options parameter https://review.opendev.org/660373 | 12:43 |
*** bobh has quit IRC | 12:48 | |
*** lbragstad has joined #openstack-oslo | 13:20 | |
*** pcaruana has quit IRC | 13:30 | |
*** pcaruana|afk| has joined #openstack-oslo | 13:30 | |
*** iurygregory has joined #openstack-oslo | 13:32 | |
*** kgiusti has joined #openstack-oslo | 14:07 | |
*** takamatsu has quit IRC | 14:18 | |
*** zaneb has joined #openstack-oslo | 14:20 | |
*** ianychoi_ is now known as ianychoi | 14:22 | |
*** iurygregory has quit IRC | 14:27 | |
*** takamatsu has joined #openstack-oslo | 14:31 | |
kgiusti | gsantomaggio: hey | 14:34 |
gsantomaggio | Hello | 14:37 |
kgiusti | gsantomaggio: sorry for the long delay - I've had lots of non-openstack stuff going on last week | 14:37 |
gsantomaggio | Don’t worry! I read your comments, and it makes sense to me. | 14:38 |
gsantomaggio | I’d like to find a common way where we agree ! :)! | 14:38 |
kgiusti | gsantomaggio: kewl - I like the options patch, but I think what sean says makes sense | 14:38 |
*** takamatsu has quit IRC | 14:38 | |
kgiusti | gsantomaggio: in the amqp1 protocol driver we've been able to detect 'no consumer' on rpc calls from the beginning | 14:39 |
kgiusti | gsantomaggio: but rabbitmq didn't give us a way to do that | 14:39 |
gsantomaggio | No consumer is different form mandatory | 14:39 |
gsantomaggio | Back to “options” | 14:40 |
gsantomaggio | What would be the right way ? In your opinion | 14:41 |
kgiusti | gsantomaggio: ugh, crap. So mandatory simply indicates queue delivery :( | 14:41 |
gsantomaggio | Yes | 14:41 |
gsantomaggio | Mandatory = the message reached at least one queue | 14:42 |
kgiusti | gsantomaggio: in my not-so-humble option I'd simply choose a more restrictive name than options | 14:42 |
gsantomaggio | Mandatory does not care about consumers | 14:43 |
gsantomaggio | (Be back in 15 minutes ) | 14:43 |
kgiusti | gsantomaggio: kk | 14:43 |
*** iurygregory has joined #openstack-oslo | 14:45 | |
*** Luzi has quit IRC | 14:54 | |
*** hberaud has quit IRC | 15:03 | |
*** hberaud has joined #openstack-oslo | 15:03 | |
gsantomaggio | @kgiusti back. | 15:16 |
gsantomaggio | So let me recap: | 15:16 |
gsantomaggio | 1- I decided to add a generic parameter called "options" ( not exactly a good name :) to pass different kind of the parameters during the "send" | 15:16 |
gsantomaggio | 2- the parameters depend on the _driver, for example RabbitMQ can be "mandatory" or "publish_confirm" or "transaction" (transaction not used for now) | 15:16 |
gsantomaggio | 3- in other context as kafka parameters like these: https://kafka-python.readthedocs.io/en/master/apidoc/KafkaProducer.html | 15:16 |
gsantomaggio | We decided to split the current pull request in two different pull requests: | 15:16 |
gsantomaggio | 1- only add the "options" parameter | 15:16 |
gsantomaggio | 2- implement mandatory flag for rabbitmq ( using the 1 ) | 15:16 |
kgiusti | gsantomaggio: yes - two pull requests == "A Good Thing" | 15:19 |
gsantomaggio | @kgiusti 👍 yes ! | 15:19 |
kgiusti | gsantomaggio: Re: options - so these are _driver_ specific options, right? | 15:20 |
gsantomaggio | @kgiusti yes | 15:21 |
kgiusti | gsantomaggio: kk - so a 'better' parameter name might be something like "transport_options" maybe? We tend to use the work "transport" in the API instead of "driver" | 15:22 |
kgiusti | gsantomaggio: s/work/word/g | 15:22 |
gsantomaggio | @kgiusti "transport_options" much much much better than my anonymous "options" | 15:23 |
kgiusti | gsantomaggio: kk +1 | 15:23 |
kgiusti | gsantomaggio: but (there's always a big but)... | 15:24 |
kgiusti | gsantomaggio: we've tried to keep the API "driver neutral" - we put driver specific stuff in the config, but never in the code API since we wanted oslo.messaging to be a generic RPC api - not specifically tied to rabbit (or kafka, or amqp 1.0, ...) | 15:27 |
kgiusti | gsantomaggio: since that makes apps hard code a dependency on the back end messaging bus | 15:28 |
kgiusti | gsantomaggio: and we've let the deployer determine which backend best fits their deployment (rabbitmq, artemis, qdr, kafka, etc) | 15:28 |
kgiusti | gsantomaggio: so this often brings up the question "what do we do if a driver does not support a particular option"? | 15:29 |
*** pcaruana|afk| has quit IRC | 15:30 | |
kgiusti | gsantomaggio: do we raise a not-implemented error and force the deployer to use a compatible back end? | 15:30 |
gsantomaggio | @kgiusti | 15:31 |
gsantomaggio | >what do we do if a driver does not support a particular option | 15:31 |
gsantomaggio | this is the common with generic layers | 15:31 |
kgiusti | gsantomaggio: or can we make transport-option values generic enough to be supported by any messaging system? | 15:31 |
gsantomaggio | @kgiusti the back-ends are totally different, Kafka and RabbitMQ implement 2 different ways to produce and consume messages. | 15:34 |
gsantomaggio | There are not common options | 15:34 |
*** notq has joined #openstack-oslo | 15:35 | |
gsantomaggio | I totally undestand the problem, I had the same problem with Kombu for example | 15:36 |
gsantomaggio | what do we do if a driver does not support a particular option | 15:36 |
gsantomaggio | ops sorry for example: https://github.com/celery/kombu/issues/1050 | 15:36 |
gsantomaggio | as you can see Kombu memory <> Kombu AMQP | 15:37 |
gsantomaggio | in short here you can't use the "mandatory" flag on your unit tests :) | 15:37 |
gsantomaggio | @kgiusti trying to maintain a clear and easy API, reduce the opportunity to use the _driver in "advanced" way | 15:39 |
gsantomaggio | @kgiusti for example oslo decided to enable "publish" confirm by default, but maybe you want to use the "transactions" instead of "confirm" | 15:41 |
kgiusti | gsantomaggio: that is very true - by abstracting out the protocol from the API we loose the ability to pass data that is available in the low level protocol specific API | 15:42 |
kgiusti | gsantomaggio: and in some cases that's going to prevent using certain features. | 15:43 |
kgiusti | gsantomaggio: however the same functionality may be offered by a different driver using different option data. | 15:44 |
kgiusti | gsantomaggio: for example 'mandatory' - that's a flag in rabbitmq recognizes to do a certain thing | 15:45 |
kgiusti | gsantomaggio: that thing (correct me if I'm wrong) is to indicate a failure if there was no queue for the given queue name (address), right? | 15:45 |
kgiusti | gsantomaggio: instead of just silently discarding the message (again correct me if I'm wrong) | 15:46 |
gsantomaggio | @kgiusti let's say " is to raise a callback if there was no queue for the given routing-key" | 15:47 |
kgiusti | gsantomaggio: kewl - yes that make sense. | 15:47 |
kgiusti | gsantomaggio: we can do the same thing in amqp1 - just a different way | 15:48 |
kgiusti | gsantomaggio: so 'mandatory' does fit the abstraction for both drivers | 15:48 |
gsantomaggio | @kgiusti in kafka there is not this kind of the concept, since producer and consumer work in the same topic | 15:48 |
kgiusti | gsantomaggio: so in kafka's case 'mandatory' is always on, since there will always be a destination (topic) | 15:49 |
kgiusti | gsantomaggio: ? | 15:49 |
gsantomaggio | @kgiusti well you cloud try to write in a not-existing partition, but let's stay on track :) | 15:51 |
kgiusti | gsantomaggio: I'm sorry - I'm bikeshedding a bit here. | 15:51 |
gsantomaggio | @kgiusti don't worry, I mean we are here to share the different knowledge | 15:52 |
kgiusti | gsantomaggio: I'm just trying to see if this can be done in a more abstract way - or, actually in a way that doesn't preclude use of a particular backend | 15:53 |
kgiusti | gsantomaggio: so what if I propose this: | 15:53 |
*** iurygregory has quit IRC | 15:54 | |
kgiusti | gsantomaggio: we define a set of transport options - | 15:54 |
kgiusti | gsantomaggio: and each driver can either support the option's behavior or raise NotImplemented... | 15:55 |
kgiusti | gsantomaggio: we would define 'mandatory' which in the case of rabbitmq would cause that callback to be invoked if no routing match | 15:55 |
kgiusti | gsantomaggio: and amqp1 would do the same behavior (just different at the protocol level) | 15:56 |
kgiusti | gsantomaggio: and if kafka cannot make that guarantee (callback if no 'topic') then it raises not implemented | 15:56 |
kgiusti | gsantomaggio: in the end, we're limited to what kombu allows us to do to some extent, right? I mean we can't influence all features of the protocol because kombu won't let us change them | 15:58 |
gsantomaggio | @kgiusti ok, what about something like this: | 16:01 |
gsantomaggio | ``` | 16:01 |
gsantomaggio | transport_options = oslo_messaging.get_transport(transport, mandatory=True) | 16:01 |
gsantomaggio | client = oslo_messaging.RPCClient(transport, target, transport_options) | 16:01 |
gsantomaggio | `` | 16:01 |
gsantomaggio | @kgiusti ok, what about something like this: | 16:01 |
gsantomaggio | ``` | 16:01 |
gsantomaggio | transport_options = oslo_messaging.get_transport(transport, mandatory=True) | 16:01 |
gsantomaggio | client = oslo_messaging.RPCClient(transport, target, transport_options) | 16:01 |
gsantomaggio | ``` | 16:01 |
gsantomaggio | or maybe better | 16:02 |
gsantomaggio | ``` | 16:03 |
gsantomaggio | transport_options = oslo_messaging.get_transport_options(transport, mandatory=True) | 16:03 |
gsantomaggio | client = oslo_messaging.RPCClient(transport, target, transport_options) | 16:03 |
gsantomaggio | ``` | 16:03 |
gsantomaggio | so we can implement the `transport_options` for each single _driver, how does it sound ? | 16:04 |
kgiusti | gsantomaggio: interesting, so what would .get_transport_options(...) return in the case of rabbitmq? {'mandatory:'True} would be my guess | 16:06 |
gsantomaggio | @kgiusti by default for the moment) `{'mandatory:'False,'publish_confirm': True, 'transaction': False}` | 16:08 |
gsantomaggio | then you can override it | 16:08 |
*** pcaruana|afk| has joined #openstack-oslo | 16:09 | |
kgiusti | gsantomaggio: ah! So get_transport_option() takes a set of keyword parameters which lets the driver translate that into driver specific parameters for the call? | 16:10 |
kgiusti | gsantomaggio: like get_transport_options(t, mandatory=True) could return {'send-unsettled: True} for amqp1 driver? | 16:11 |
kgiusti | gsantomaggio: which would give us the same behavior | 16:11 |
gsantomaggio | @kgiusti something like that, maybe we can call them with a more "abstract" names | 16:12 |
gsantomaggio | I'd start with "mandatory", then we will see the others | 16:13 |
kgiusti | gsantomaggio: bravo! Yes _that's_ perfect - you're able to express that well. | 16:13 |
kgiusti | gsantomaggio: +2 | 16:13 |
gsantomaggio | @kgiusti @bnemec @hberaud @ansmith_ we agree ? | 16:14 |
gsantomaggio | 3... | 16:14 |
gsantomaggio | 2... | 16:14 |
gsantomaggio | 1... | 16:14 |
bnemec | I'm just catching up, but this all sounds reasonable to me. | 16:14 |
kgiusti | yay! | 16:14 |
gsantomaggio | 0... | 16:14 |
gsantomaggio | Cool! thank you guys ! will work on it, does it make sense to close the current review and start with a new one ? @kgiusti | 16:15 |
gsantomaggio | or use the same one to take the story? | 16:16 |
hberaud | +1 | 16:16 |
bnemec | gsantomaggio: I'd stick with the same one so we have a history of the discussion that led us to this design. | 16:16 |
kgiusti | gsantomaggio: +1 | 16:16 |
gsantomaggio | ok great! | 16:17 |
gsantomaggio | leaving ! great progress today ! :)! | 16:17 |
bnemec | gsantomaggio: If you want to start the commit over from scratch, you can just copy the Change-Id line into the new commit message and it will get pushed to gerrit as the same change. | 16:17 |
hberaud | gsantomaggio: w00t! | 16:17 |
bnemec | gsantomaggio: Thanks for sticking with this! | 16:17 |
kgiusti | gsantomaggio: yes indeed - thanks! | 16:19 |
*** e0ne has quit IRC | 16:44 | |
*** tosky has joined #openstack-oslo | 17:05 | |
*** ianychoi has quit IRC | 17:25 | |
*** hberaud is now known as hberaud|afk | 17:34 | |
*** e0ne has joined #openstack-oslo | 18:10 | |
*** e0ne has quit IRC | 18:12 | |
*** e0ne has joined #openstack-oslo | 18:12 | |
*** e0ne has quit IRC | 18:17 | |
*** e0ne has joined #openstack-oslo | 18:19 | |
*** e0ne has quit IRC | 18:35 | |
*** tesseract has quit IRC | 18:54 | |
*** e0ne has joined #openstack-oslo | 19:23 | |
*** e0ne has quit IRC | 19:26 | |
*** tosky has quit IRC | 19:26 | |
*** ralonsoh has quit IRC | 19:50 | |
*** hoonetorg has quit IRC | 19:51 | |
*** hoonetorg has joined #openstack-oslo | 20:03 | |
*** hberaud|afk is now known as hberaud | 20:05 | |
*** ansmith_ has quit IRC | 20:50 | |
*** kgiusti has left #openstack-oslo | 21:06 | |
*** boden has quit IRC | 21:10 | |
*** pcaruana|afk| has quit IRC | 21:16 | |
openstackgerrit | Merged openstack/oslo.log master: Fix guidelines w.r.t. translation of log messages https://review.opendev.org/664855 | 21:31 |
*** raildo has quit IRC | 21:47 | |
*** notq has quit IRC | 22:12 | |
*** ansmith_ has joined #openstack-oslo | 22:38 | |
*** rcernin has joined #openstack-oslo | 22:41 | |
*** lifeless has quit IRC | 23:05 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!