15:01:23 <noonedeadpunk> #startmeeting openstack_ansible_meeting
15:01:23 <opendevmeet> Meeting started Tue Sep  1 15:01:23 2026 UTC and is due to finish in 60 minutes.  The chair is noonedeadpunk. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:23 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:23 <opendevmeet> The meeting name has been set to 'openstack_ansible_meeting'
15:01:31 <noonedeadpunk> #topic rollcall
15:01:34 <noonedeadpunk> o/ hey there
15:01:37 <jrosser> o/ hello
15:03:55 <noonedeadpunk> #topic releases
15:04:13 <noonedeadpunk> so I have completely missed 2024.2 EOL deadline
15:04:21 <noonedeadpunk> and frankly clean forgot about it at all
15:04:40 <noonedeadpunk> during this week roles have been EOLed and branches dropped
15:05:03 <noonedeadpunk> now the only part left is integrated repo
15:05:06 <noonedeadpunk> #link https://review.opendev.org/c/openstack/openstack-ansible/+/1002737
15:05:23 <noonedeadpunk> surprisingly, CI looks quite functional, with exception of upgrade jobs
15:05:57 <noonedeadpunk> so potentially it should be votable soonish
15:06:13 <noonedeadpunk> second part are periodic releases of stable branches
15:06:27 <noonedeadpunk> frankly, I am waiting for keystone backports to merge now
15:07:00 <noonedeadpunk> to make sure new point releases contain fixes for OSSA-2026-037 among other things
15:07:38 <noonedeadpunk> and keystone CI fails intermittently so far
15:08:56 <noonedeadpunk> so while we are waiting, we might want to merge the sha bump for octavia specifically, to unblock backports to 2026.1
15:08:57 <noonedeadpunk> #link https://review.opendev.org/c/openstack/openstack-ansible/+/1003256
15:09:18 <opendevreview> Ivan Anfimov proposed openstack/openstack-ansible-os_octavia stable/2026.1: Return ZooKeeper  https://review.opendev.org/c/openstack/openstack-ansible-os_octavia/+/999957
15:09:23 <jrosser> done
15:09:46 <noonedeadpunk> thanks!
15:10:02 <noonedeadpunk> and I don't have much to add on the topic here
15:11:35 <noonedeadpunk> #topic office hours
15:11:54 <noonedeadpunk> So there was a great patch pushed to the ops repo during previous week
15:11:58 <noonedeadpunk> #link https://review.opendev.org/c/openstack/openstack-ansible-ops/+/1002724
15:12:40 <noonedeadpunk> While we probably can merge it "as-is" I was thinking to spend couple of hours looking into how we may "collectify" it.
15:12:55 <noonedeadpunk> But this can be done as a follow-up as well, for sure
15:13:09 <jrosser> yes, i think in hindsight andrew feels it would have been better to make it so it runs from the deploy host, rather than independany
15:13:36 <jrosser> it ended up needing to understand to OSA inventory to get into some neutron containers
15:13:54 <noonedeadpunk> I guess the question is if we wanna work on this patch or merge it and do follow-ups?
15:14:19 <jrosser> I think that from our POV this has already taken so much time that we actually need to get on and do the migrations
15:15:05 <noonedeadpunk> I think I should be able to invest some time into it, as I am personally very interested in the topic
15:15:35 <jrosser> This is probably the most complete description of the steps involved anyone has made
15:15:42 <noonedeadpunk> ++
15:16:29 <noonedeadpunk> ok, I think we can probably merge this and I will propose changes/refactoring as a follow up, to better keep history, and have smth out asap
15:16:55 <jrosser> Yeah, i think it would be good to put something on the ML too at some point
15:17:38 <noonedeadpunk> I will aim to get some time during this week for it
15:17:55 <jrosser> It looks like for us it is mostly all fine in OVN - just OVN FWaaS being stateless is a bit unfortunate
15:18:06 <jrosser> but andrew has been looking into that
15:18:25 <noonedeadpunk> I thought that fwaas does work with ovn these days?
15:18:44 <jrosser> yes, statless FW instead of connection tracked though
15:19:07 <noonedeadpunk> as well as vpnaas, just through spawning a good old namespace and wasting another IP
15:19:08 <jrosser> the old one that ran on the l3 agent was more powerful/easier for our use case
15:19:49 <jrosser> i think that there is an assumption that FW rules can be == to security groups
15:19:55 <jrosser> and thats kind of fine for VM
15:20:28 <jrosser> but when you have some random harware appliances also on your tenant networks next to the VM then you need something thats not security groups on a neutron port
15:21:50 <noonedeadpunk> yeah, totally
15:22:42 <noonedeadpunk> for some reason I thought that it was the same iptables in ip netns before the l3 router, so it had same feature set
15:23:17 <noonedeadpunk> but we're not using fwaas so I didn't dig deep enough there
15:25:16 <noonedeadpunk> this week I didn't have much progress on any of planned things, except finding couple of bugs in os_freezer role
15:26:04 <noonedeadpunk> first one is that freezer-api and freezer are 2 different packages, which I tried to wrap around with logic, and install them only whenever needed
15:26:28 <noonedeadpunk> which actually resulted in rebuilding requrements file, and triggerring venv/wheels rebuild as a result
15:26:59 <noonedeadpunk> #link https://review.opendev.org/c/openstack/openstack-ansible-os_freezer/+/1003087
15:27:51 <noonedeadpunk> And second issue I found in there, is that jobs directory, where scheduler places cached jobs from API, was in /etc/freezer, which is a symlink to venv, so when venv is being rebuild, these state files are lost.
15:28:05 <noonedeadpunk> #link https://review.opendev.org/c/openstack/openstack-ansible-os_freezer/+/1003081
15:29:11 <opendevreview> Merged openstack/openstack-ansible-os_freezer master: Implement freezer-scheduler clustering support  https://review.opendev.org/c/openstack/openstack-ansible-os_freezer/+/998718
15:29:39 <noonedeadpunk> we're having really good progress in deploying freezer in production now
15:29:48 <noonedeadpunk> still quite some work to do obviously
15:30:24 <noonedeadpunk> and I am expecting to have some more time on my hands once we're done with it.
15:30:43 <jrosser> i should look at freezer myself some more
15:31:07 <opendevreview> Ivan Anfimov proposed openstack/openstack-ansible-os_octavia stable/2026.1: Use RHEL OS family for iptables persistence  https://review.opendev.org/c/openstack/openstack-ansible-os_octavia/+/1003278
15:31:20 <noonedeadpunk> if you be looking, look at the master branch only. plenty of things were landed for 2026.2 in there
15:32:27 <noonedeadpunk> and the last topic that is around was pep503, but we've discussed it already quite extensively
15:32:32 <noonedeadpunk> #link https://review.opendev.org/q/topic:%22osa/pep503%22
15:32:58 <noonedeadpunk> I don't think I have much more findings there, except fixed documentation and re-added example of passing custom pip.conf
15:33:22 <noonedeadpunk> and so far I decided not to go with this one
15:33:24 <noonedeadpunk> #link https://review.opendev.org/c/openstack/openstack-ansible-openstack_hosts/+/1001222
15:33:46 <noonedeadpunk> as I feel it as quite controversial in general....
15:33:57 <noonedeadpunk> but dunno
15:34:36 <opendevreview> Merged openstack/openstack-ansible-ops master: Add sample playbooks to aid in conversion from lxb to ovn  https://review.opendev.org/c/openstack/openstack-ansible-ops/+/1002724
15:37:28 <jrosser> thats relying on the repo server to fallback to a local mirror instead of using pip.conf?
15:38:27 <noonedeadpunk> https://review.opendev.org/c/openstack/openstack-ansible-openstack_hosts/+/1001222 is to actually manage pip.conf with osa role - the one I am not sure about
15:38:50 <noonedeadpunk> fallback from repo server to a local mirror so far looks as quite a good idea overall
15:38:51 <jrosser> yep
15:39:26 <jrosser> depending on the environment you might need that in place very early to then have anything else work
15:39:33 <noonedeadpunk> the thing is that if there is a pip.conf, pip will add the index-url to the list, and will consult it for each package request
15:39:58 <noonedeadpunk> which raises response/build time quite significantly
15:41:00 <noonedeadpunk> and the idea behind https://review.opendev.org/c/openstack/ansible-role-python_venv_build/+/985531 is to produce proper simple repository confirmant for PIP to respect/trust it enough, with a fallback configured on repo server
15:42:10 <noonedeadpunk> well, I think openstack_hosts is actually early enough. But then fact of having pip.conf on hosts and/or containers is probably not always a good idea. and then upgrade path is very tricky
15:44:16 <noonedeadpunk> but yeah, I guess that's it from my side
15:45:41 <opendevreview> Ivan Anfimov proposed openstack/openstack-ansible-os_magnum master: Add information about manage configuration by OSA  https://review.opendev.org/c/openstack/openstack-ansible-os_magnum/+/972889
15:46:10 <noonedeadpunk> As of CI state. It seems that we're mostly good, but feels like quite some "intermittent" issues with magnum are happening
15:49:12 <noonedeadpunk> and mostly for EL distros, after 16gb instances were disabled for debian
15:49:42 <noonedeadpunk> as it's really a heavy test we're trying to run there...
16:11:25 <noonedeadpunk> #endmeeting