16:00:33 <gthiemonge> #startmeeting Octavia
16:00:33 <opendevmeet> Meeting started Wed Mar 13 16:00:33 2024 UTC and is due to finish in 60 minutes.  The chair is gthiemonge. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:33 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:33 <opendevmeet> The meeting name has been set to 'octavia'
16:00:38 <tweining> o/
16:00:41 <gthiemonge> hi
16:00:58 <johnsom> o/
16:01:15 <oschwart> o/
16:02:24 <gthiemonge> #topic Announcements
16:02:29 <gthiemonge> * 2024.1 Caracal Release Schedule: RC1
16:02:50 <gthiemonge> This is the RC1 milestone this week
16:03:01 <gthiemonge> we don't expect to have another RC unless we find a critical bug
16:03:10 <gthiemonge> so Octavia RC1 should be the version for Caracal
16:03:30 <gthiemonge> right now we are only waiting for https://review.opendev.org/c/openstack/octavia/+/912599 to pass the CI (patch already approved)
16:03:39 <gthiemonge> then I'll update the hash in the release patch
16:04:22 <johnsom> Sounds good. Did your reload patch land? I saw that was holding up the above bug
16:04:45 <gthiemonge> nop
16:04:47 <gthiemonge> https://review.opendev.org/c/openstack/octavia/+/909849
16:05:23 <johnsom> Ok, I will be looking at that
16:05:34 <gthiemonge> thanks
16:06:29 <gthiemonge> * Dalmatian PTG
16:06:39 <gthiemonge> reminder: the PTG is next month
16:06:44 <gthiemonge> I created an etherpad
16:07:03 <gthiemonge> https://etherpad.opendev.org/p/apr2024-ptg-octavia
16:07:10 <gthiemonge> you can add your topics there
16:07:56 <gthiemonge> I haven't yet scheduled our session, IIRC the previous one was on Tuesday at 1400 UTC, maybe I'll book the same timeslot
16:08:07 <gthiemonge> WDYT?
16:08:34 <oschwart> sounds good to me
16:08:54 <johnsom> Yeah, that works for me
16:09:04 <tweining> for me too
16:09:51 <gthiemonge> cool
16:10:01 <gthiemonge> that's all I have for the announcements, did I miss something?
16:12:00 <tweining> isn't now ptl election period?
16:12:34 <johnsom> It is over:
16:12:36 <johnsom> #link https://governance.openstack.org/election/
16:12:52 <johnsom> Congrats to gthiemonge!
16:13:01 <tweining> ah, thanks. congrats btw
16:13:01 <gthiemonge> \o/
16:13:29 <oschwart> congratulations gthiemonge!
16:13:38 <johnsom> There were no contested projects, so the PTL election is over
16:15:03 <gthiemonge> maybe in 6 months
16:15:58 <johnsom> We could also mention there is going to be an OpenStack Summit Asia in South Korea in September.
16:16:23 <johnsom> In case anyone is interested, the call for presentations is open
16:16:44 <johnsom> #link https://openinfra.dev/summit/
16:16:48 <gthiemonge> OpenInfra Days in Europe too
16:16:57 <gthiemonge> #link https://oideurope2024.openinfra.dev/#registration=1
16:19:04 <gthiemonge> #topic CI Status
16:19:36 <gthiemonge> so, on the CI, there are still some issue with haproxy, but it looks a bit better than the past week
16:19:53 <gthiemonge> as mentioned earlier, https://review.opendev.org/c/openstack/octavia/+/909849 is a workaround for this issue
16:19:54 <johnsom> Yeah, it is still crashing for some reason
16:20:46 <gthiemonge> if I can find some time, I'll investigate but it looks like an ubuntu-only bug
16:21:14 <johnsom> Yeah, I am pretty convinced it is a bug in the ubuntu version of haproxy
16:23:24 <gthiemonge> +1
16:25:13 <gthiemonge> #topic Brief progress reports / bugs needing review
16:26:09 <gthiemonge> I found and fixed a bug with the fully-populated LB API when using allowed_cidrs in the listener
16:26:13 <gthiemonge> https://review.opendev.org/c/openstack/octavia/+/912721
16:26:25 <johnsom> I fixed one open issue with the SR-IOV patch that gthiemonge noticed, where the failover flow was not honoring the Amphora api timeouts, so failover could be longer than desired. That is in the testing gates now
16:26:27 <gthiemonge> https://bugs.launchpad.net/octavia/+bug/2057751
16:27:51 <johnsom> Otherwise, I am starting work on SR-IOV for members next
16:29:31 <oschwart> I have this very WIP fix from the past:
16:29:36 <oschwart> https://review.opendev.org/c/openstack/octavia/+/887593
16:30:01 <oschwart> I wanted to consult with you guys about the idea behind it
16:30:20 <gthiemonge> yeah I looked at it
16:30:20 <oschwart> (assuming that a little more effort will make the implementation much better)
16:30:57 <gthiemonge> I think we need to split the _graph_create function of each controller into 2 functions: _graph_validate & _graph_creates
16:31:14 <gthiemonge> and _graph_validate would be called before the creation of the port in neutron
16:32:28 <oschwart> sounds good to me. (or any way of validating the parameters of the LB before starting to create resources)
16:32:41 <oschwart> s/LB/listeners+pools
16:32:45 <gthiemonge> we need to check that it's possible with the validation functions, it depednds on the type of the params they receive
16:32:56 <johnsom> I wonder if that is related to: https://review.opendev.org/c/openstack/octavia/+/910449
16:33:40 <gthiemonge> no the issue happens in the API only, the VIP port is created before the subresources are validated
16:34:12 <johnsom> Does the LB go to provisioning state of ERROR?
16:34:14 <gthiemonge> so if the validation of a port/listener/etc... fails, an exception is raised, the API returns an error, but the port is still there
16:34:30 <gthiemonge> nop, no LB in the DB, only a dangling port
16:34:49 <johnsom> Ah, so it doesn't go into the flow yet. Got it
16:35:00 <gthiemonge> yeah only in the API
16:35:48 <gthiemonge> another solution would be to delete the port when an exception is raised, but there's no direct access to the neutron API, we need to update and pass through the provider driver, so it would be an unbackportable change
16:36:48 <johnsom> Yeah, that is a bit nasty as it could lock up a requested fixed IP.
16:37:19 <oschwart> I prefer calling the validation functions, we already have them implemented, at least almost fully
16:38:49 <gthiemonge> +1
16:40:50 <johnsom> We should think about how to cleanup as well, i.e. if the DB commit fails due to the DB going down, would we end up in the same situation.
16:41:06 <gthiemonge> right
16:42:16 <tweining> I think we didn't discuss our policy about backporting to the new unmaintained/* branches in the future. Will we stop backporting fixes to those branches upstream?
16:42:42 <tweining> (I just remember we did not discuss that yet, I think)
16:43:16 <gthiemonge> maybe a good topic for the PTG, I'm a bit annoyed because all the backports I created for stable/* were abandonned when the branches were renamed
16:43:56 <tweining> ok. i'll add it to the epad
16:44:13 <johnsom> Yeah, that is a good PTG topic
16:45:20 <gthiemonge> #topic Open Discussion
16:45:26 <gthiemonge> I think we're already there
16:45:59 <tweining> nothing else from me
16:46:32 <johnsom> Yeah, I don't think I have anything else
16:46:51 <oschwart> me neither
16:47:02 <gthiemonge> okay
16:47:11 <gthiemonge> thank you guys! good discussions!
16:47:17 <gthiemonge> #endmeeting