16:00:00 <johnsom> #startmeeting Octavia
16:00:00 <opendevmeet> Meeting started Wed Jan 28 16:00:00 2026 UTC and is due to finish in 60 minutes.  The chair is johnsom. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:00 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:00 <opendevmeet> The meeting name has been set to 'octavia'
16:00:07 <gthiemon1e> o/
16:00:09 <johnsom> Hello everyone
16:00:17 <gthiemonge> o/
16:00:58 <johnsom> #topic Announcements
16:01:13 <johnsom> I do not have any new announcements this week. Does anyone else?
16:01:28 <gthiemonge> hmm, no
16:01:54 <raineszm> o/
16:01:57 <johnsom> #topic Brief progress reports / bugs needing review
16:03:07 <gthiemonge> quite busy week for me, but not with upstream octavia :D
16:03:08 <johnsom> About all I have on the progress side here is we did a stable/2024.2 release of Octavia.
16:03:36 <johnsom> Yeah, same, I am still held up helping Designate with the eventlet removal.
16:03:46 <gthiemonge> johnsom: hey, this patch has been there for a few weeks now, it's a fix for a broken RPC call:
16:03:51 <gthiemonge> https://review.opendev.org/c/openstack/octavia/+/969195
16:04:57 <johnsom> Ok, I will have a look
16:05:02 <gthiemonge> thanks
16:05:33 <RomanHros[m]> Hello, what is progress in https://bugs.launchpad.net/octavia/+bug/2133042?
16:06:36 <gthiemonge> I think it's stuck, the idea of adding dependencies between the tasks in taskflow doesn't work
16:06:42 <johnsom> What I remember is this is really a bug in Nova. I should re-read it and re-assign it to nova
16:06:57 <gthiemonge> Nova just says "don't do that"
16:07:23 <johnsom> Well, like many of the other nasty bugs in nova...
16:07:27 <gthiemonge> they provide an API to create multiple servers, but it's not compatbile with the config drive we pass
16:07:52 <johnsom> Yeah, that API is very limited in capability.
16:08:12 <gthiemonge> basically we had 2 ideas: dealing with this issue in taskflow, or spliting the flows in octavia to run those 2 tasks sequentially
16:08:39 <johnsom> Or fixing nova, which is the right answer
16:08:51 <RomanHros[m]> Is it hard to just change the engine to serial for the VM creation process?
16:09:28 <johnsom> It is not hard, but will significantly slow the load balancer provision process. The nova boot is already the slowest step in the process.
16:10:10 <johnsom> I would guess we would go from 45 seconds to provision a load balancer to a minute and a half if we serialize that step.
16:10:19 <gthiemonge> johnsom: it's only the API calls that should not be made in parallel, once the POST are sent, we can probably continue the flow in parallel
16:11:12 <gthiemonge> at least after creating the VM we should ensure that it is assigned to an host before continuing
16:11:24 <johnsom> Hmmm, I wonder if there is impact on the rollback/retries in that scenario
16:12:11 <gthiemonge> yeah we've had a few bugs with the revert of unordered flows :/
16:12:15 <johnsom> Yeah, this is all the whole point of having a server affinity group in nova. It seems like  they need a simple lock on the affinity group to stop this broken behavior
16:14:20 <gthiemonge> another workaround would be to check the status of the MASTER amphora VM before creating the BACKUP amphora VM
16:14:42 <gthiemonge> no changes in the flows, just a short wait in the create-server task
16:15:09 <RomanHros[m]> until it has host assigned?
16:15:11 <johnsom> We can think about adding yet another workaround for nova, but I think we also need to push nova to fix the placement service like they mention in the document.
16:15:47 <johnsom> Any change we do will slow the provisioning process which people already think that 45 seconds is too long.
16:16:03 <gthiemonge> "Future work" but it was 2021-07-09 :D
16:16:09 <johnsom> Yeah
16:18:21 <gthiemonge> I can measure the impact of a delay before sending the 2nd create server
16:18:36 <johnsom> RomanHros[m] Do you know if there is an existing bug open in nova for this issue?
16:19:20 <gthiemonge> johnsom: https://bugs.launchpad.net/nova/+bug/2132984
16:20:19 <johnsom> Yeah, checking the status before launching the second might be the best workaround. There is a "starting/booting" state that nova flips to once the qemu process is launched, that might be the trigger if there isn't a host assigned column we can use.
16:23:34 <gthiemonge> I'll report my findings in the launchpad
16:23:51 <johnsom> Thank you
16:24:29 <johnsom> Any other progress updates this week?
16:25:03 <gthiemonge> that's all from me
16:25:23 <johnsom> #topic Open Discussion
16:25:28 <johnsom> Any other topics this week?
16:25:33 <raineszm> Two minor things for me
16:25:43 <raineszm> One of my stable backports got passed over #link https://review.opendev.org/c/openstack/octavia/+/967755
16:25:50 <raineszm> Totally my fault for doing them all at once
16:25:58 <raineszm> Thanks for you patience with these
16:26:21 <raineszm> And an o-t-p patch to fix CI on unmaintained branches #link https://review.opendev.org/c/openstack/octavia-tempest-plugin/+/974565
16:26:23 <johnsom> Oh, that is my mistake most likely. Sorry about that
16:26:45 <raineszm> No worries.
16:27:13 <gthiemonge> yeah i'm confused with the presence of unmaintained branches in octavia-tempest-plugin master
16:27:41 <gthiemonge> doesn't it work because your patch on the unmaintained branch has a depends-on the change in o-t-p master?
16:27:51 <raineszm> It is a little funky.
16:27:52 <raineszm> Yes.
16:28:11 <raineszm> So o-t-p master specializes some parent jobs to be on jammy for unmaintained
16:28:13 <gthiemonge> but the unmaintained branch will never use o-t-p master, even when the patch merges, so I don't know if it will eventually work
16:29:08 <gthiemonge> or is it only the zuul config of o-t-p master that matters for all the branches?
16:29:26 <raineszm> I thought it was only the master config, like tempest. But I can double check.
16:29:31 <gthiemonge> hmm
16:29:33 <raineszm> It's been a few weeks since I looked at that
16:30:00 <raineszm> there's no special branches
16:30:03 <johnsom> Octavia tempest plugin in branchless in theory. In practice that has been a problem and tempest has used tags to work around it.
16:30:38 <gthiemonge> yeah it should be pinned for unmaintained/
16:30:50 <johnsom> Yes
16:30:59 <gthiemonge> well, maybe we can merge the o-t-p change, and see what happens, the patch looks harmless for the other jobs
16:32:50 <raineszm> I don't see anything in the unmaintained branches pinning o-t-p to a tag currently
16:32:57 <gthiemonge> i've just CR+2 the o-t-p review
16:33:01 <raineszm> ty
16:33:47 <johnsom> Yeah, that patch will be ok until we get an unmaintained release on noble.
16:35:23 <johnsom> I workflowed it, but we will need to readdress that in the future.
16:35:29 <johnsom> Any other topics today?
16:35:31 <raineszm> johnsom: noted
16:35:33 <raineszm> that's it for me
16:35:47 <theovg> Hey! About my patch, I'm particularly available to work on it at the moment; if you have a bit of time to spare for reviewing it that would be very appreciated https://review.opendev.org/c/openstack/octavia/+/970404
16:36:42 <gthiemonge> theovg: hey, I saw your update, I'll take a look
16:36:44 <johnsom> theovg Thank you for your work on that. I have not had time to look at it yet.
16:37:15 <theovg> Thank you very much :)
16:37:18 <gthiemonge> I need to do more tests with unreasonable amounts of resources
16:39:22 <johnsom> Ok, if that is it for this week we can wrap it up. Good discussions!
16:39:44 <johnsom> #endmeeting