16:00:02 <johnsom> #startmeeting Octavia
16:00:02 <opendevmeet> Meeting started Wed Jul 16 16:00:02 2025 UTC and is due to finish in 60 minutes.  The chair is johnsom. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:02 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:02 <opendevmeet> The meeting name has been set to 'octavia'
16:00:07 <danfai> o/
16:00:08 <gthiemonge> o/
16:00:15 <johnsom> Hi everyone
16:00:34 <johnsom> #topic Announcements
16:01:13 <johnsom> The only announcement I have this week is that stable/2024.1 is heading towards unmaintained. I approved a bunch of final releases this last week.
16:02:21 <johnsom> Any other announcements this week?
16:02:33 <danfai> not from my side
16:02:44 <gthiemonge> nop
16:02:47 <johnsom> #topic Brief progress reports / bugs needing review
16:03:27 <johnsom> I have mostly been working on reviews upstream. Downstream there have been other distractions as well.
16:03:52 <johnsom> I have been trying to research more about the pyproject.toml transition, so that is still WIP.
16:03:53 <gthiemonge> I opened a launchpad for a random unit test failure in the CI (with a test function recently added) https://bugs.launchpad.net/octavia/+bug/2116915
16:04:02 <gthiemonge> I'm going to propose a patch to fix the test tomorrow
16:04:21 <johnsom> +1
16:04:44 <gthiemonge> (the failure was reported by frickler last week ^^)
16:05:10 <danfai> i was on pto, and will be again on pto the next weeks. Reading last meetings notes, I saw maybe I was missing some more release notes, so updated the review for that. thanks for the +2
16:05:38 <johnsom> Thank you!
16:05:43 <danfai> otherwise I was previously having this issue downstream: #link https://bugs.launchpad.net/octavia/+bug/2114264
16:06:43 <danfai> The question would be if we can somehow make the value for the ipvsadm timeout configurable to actually failover quicker
16:07:07 <gthiemonge> hmm interesting
16:08:17 <danfai> The problem we are facing, the client will always use the same IP+src port and sends pings multiple times per second. Thus it will always go to the same backend, and for quite a long time even if the backend is marked down
16:09:41 <johnsom> Yeah, same, I would have expected that setting to be tuned with the health manager timeout/retry settings
16:10:57 <danfai> I think a question will be how to properly translate it to the correct value and set it accordingly.
16:11:09 <gthiemonge> we have some timeout settings in the listener API, they are probably unused for UDP, maybe we can find one setting that would fit
16:11:40 <danfai> While our use-case does not care which backend it sends the traffic to, other use-cases might want to have bidirectional communication, and too low timeouts would break this
16:11:43 <johnsom> Let me play around with this a bit. I will post updates on the bug
16:11:51 <danfai> thanks
16:12:28 <danfai> feel free to ping me in the ticket/here if you need more info, if I see it I'll reply
16:12:50 <johnsom> UDP is an challenging case given the stateless nature. We rely on ICMP pretty heavily there to detect failed member services.
16:14:09 <johnsom> Thanks for opening a bug for it.
16:15:05 <johnsom> To clarify, it's load balancing UDP traffic, but the health monitor is checking over HTTP?
16:15:11 <danfai> correct
16:15:32 <danfai> I see, I forgot a reproducer in the ticket, will add some more infos
16:15:48 <johnsom> Ok. A scenario that probably is not tested well
16:17:02 <johnsom> Thanks, a reproducer would be great
16:17:51 <johnsom> #topic Open Discussion
16:17:59 <johnsom> Any other topics for today?
16:18:17 <danfai> nop
16:18:21 <gthiemonge> nop
16:19:11 <johnsom> Ok, that is all I have too.
16:19:17 <johnsom> Have a great week and  PTO!
16:19:26 <johnsom> #endmeeting