14:00:40 <haleyb> #startmeeting neutron_drivers
14:00:40 <opendevmeet> Meeting started Fri Dec  1 14:00:40 2023 UTC and is due to finish in 60 minutes.  The chair is haleyb. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:40 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:40 <opendevmeet> The meeting name has been set to 'neutron_drivers'
14:00:45 <mlavalle> \o
14:00:50 <lajoskatona> o/
14:01:26 <haleyb> i'm hoping ihrachys_ saw my email about his RFE
14:02:08 <haleyb> but we don't have quorom yet, lets wait
14:02:13 <haleyb> #link https://bugs.launchpad.net/neutron/+bug/2045058
14:02:21 <haleyb> in case anyone wants to read
14:02:26 <obondarev> o/
14:04:41 <ihrachys_> I did not see it yet but I will check
14:05:12 * mlavalle reading
14:05:31 <haleyb> ihrachys_: since it was tagged as an rfe i added it to the agenda
14:05:44 <ihrachys_> so long story short, neutron manually manages long RPC calls; and oslo.messaging already supports something similar (or better) so we could adopt it
14:06:14 <ihrachys_> (better because clients heartbeat and not just timeout on long calls)
14:07:24 <haleyb> ihrachys_: yes, it seemed to me like a good change, especially since another project has a blueprint to follow
14:07:35 <obondarev> can we adopt it without disabling neutron mechanism? Thus we'll have some backup mechanism and potentially we can see which is working better in our case
14:08:02 <obondarev> and eventually disable another
14:08:02 <lajoskatona> This is the oslo patch which introduces the option (I can't find the doc); https://review.opendev.org/c/openstack/oslo.messaging/+/546763
14:08:12 <haleyb> i forgot the ping...
14:08:16 <haleyb> ping ykarel, mlavalle, mtomaska, slawek, obondarev, tobias-urdin, lajoskatona, amotoki
14:08:22 <mlavalle> LOL
14:08:23 <ihrachys_> I think we can adopt step by step and it seems like a good approach
14:08:26 <mlavalle> I'm here
14:08:41 <haleyb> it was just a blind copy/paste :)
14:09:18 <lajoskatona> The nova patch you referenced in RFE do this only for longer than 60sec calls, or am I misunderstood?
14:09:22 <ihrachys_> backoff client activates its logic on MessagingTimeout so if oslo.msg doesn't return it, it should be NOOP
14:09:51 <ihrachys_> lajoskatona I think so and I believe it's because they don't expect timeouts from calls that are shorter than 60s?
14:10:19 <lajoskatona> ihrachys_: good explanation, so possible
14:10:35 <obondarev> ihrachys_: perfect then, so no need to immediately disable neutron lib backoff
14:10:36 <ihrachys_> probably some optimization not to send too many heartbeats; good point and we should check with nova why they do it
14:11:10 <ihrachys_> I can check with dan who posted the nova patch
14:11:25 <ihrachys_> actually he's here dansmith
14:12:17 <mlavalle> wow, what an honor... dansmith is here!
14:12:33 <ihrachys_> "keep the failure timing characteristics that our code likely expects (from history)" in code, not sure what it means :)
14:13:50 <haleyb> was that really from 5 years ago in nova? wow
14:14:37 <mlavalle> that;s what the commit says
14:14:45 <ihrachys_> yes. Dan told me about it half a year ago and I just got to post it in launchpad so...
14:15:34 <haleyb> i would be curious if it worked as they intended, and also if it code has changed since then
14:16:08 <lajoskatona> +1
14:16:58 <ihrachys_> Dan mentioned it to me when he heard that we still manually bump timeouts in high scale envs; and said this approach works for them fine.
14:17:05 <ihrachys_> (and so we should adopt it)
14:17:16 <haleyb> ihrachys_: ack
14:17:36 <haleyb> so i think the only problem is we don't have quorom to vote, i only counted 4 of us
14:18:14 <mlavalle> it looks very reasonable to me
14:18:28 <mlavalle> ihrachys_: will you implement it?
14:18:29 <haleyb> but i think it's a good idea, on the fence if it even needs a spec
14:18:52 <ihrachys_> mlavalle: I will
14:19:09 <mlavalle> I don't feel we need a spec. Maybe use the first few revisions to the patch as a PoC and see how it goes
14:19:22 <lajoskatona> agree
14:22:02 <mlavalle> count my vote as +1, either today or next meeting
14:22:24 <lajoskatona> I would say, let's add some more details to the RFE like how it works for nova, how to handle shorter that 60sec calls etc, and push PoCn ad if we need formal vote lets do it in a following drivers meting or even team meeting
14:22:39 <ihrachys_> ack
14:22:50 <lajoskatona> +1 from me also
14:22:58 <ihrachys_> I will probably post patches in the next year though :)
14:23:23 <haleyb> all sounds good, +1 from me as well, if you want to start work we can just table vote until next meeting
14:23:40 <mlavalle> lajoskatona: good approach. this way we don't waste ihrachys_ time and he can move forward, whenever the upcoming holidays season allow him
14:23:57 <obondarev> +1 for the RFE
14:24:01 <lajoskatona> +1for holiday season :P
14:24:29 <haleyb> ihrachys_: i will keep on agenda for next week if you like and will be around
14:24:34 <mlavalle> ihrachys_: I don't think we are in a rush for this. We've waited 5 years, I think we will survive another couple of months :-)
14:25:11 <mlavalle> and thanks for bringing this up!
14:25:30 <mlavalle> I think it is a worthwhile optimization
14:25:59 <haleyb> are there any other rfe's to discuss? otherwise i can let everyone go back to Review Days! :)
14:26:58 <haleyb> i will take that as a No
14:27:10 <ihrachys_> o/
14:27:15 <haleyb> have a good weekend everyone, and thanks ihrachys_
14:27:19 <haleyb> #endmeeting