15:03:49 #startmeeting openstack_ansible_meeting 15:03:49 Meeting started Tue May 27 15:03:49 2025 UTC and is due to finish in 60 minutes. The chair is noonedeadpunk. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:03:49 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:03:49 The meeting name has been set to 'openstack_ansible_meeting' 15:03:54 #topic rollcall 15:03:59 o/ hello 15:04:02 o/ 15:04:25 sorry for being late 15:06:01 o/ 15:07:51 #topic office hours 15:08:02 o/ 15:08:25 I think the main topic - what do we want/need to merge to Epoxy berfore doing RC2 and a 31.0.0 tag? 15:09:30 As I'd love to propose a release by end of this week, not to face any unexpected delays 15:09:36 it feels tlike things are reasonably stable? 15:10:14 yes, I think they are 15:10:33 though this cycle it is very unlikley that I will be able to get any lab testing of Epoxy done in the short term 15:11:07 I think we will be doing this during July/August at very least 15:11:12 Caracal -> Epoxy one 15:11:44 this is probably our worst upgrade ever as it will be opesntack + ubuntu + lb->ovn 15:12:14 Upgrading OVN with Ubuntu might be problematic 15:12:30 oh yes, that not necessarily all in one shot 15:12:31 there is a bug report I never looked into much 15:12:50 https://bugs.launchpad.net/openstack-ansible/+bug/2059721 15:13:04 it's from 2023.1, but we have not changed much in logic around OVN clustering setup 15:13:22 and it totally looks like a race condition/compatability issue between major OVN versions 15:14:02 so that can be really a problem 15:14:23 Merged openstack/openstack-ansible master: docs: fix small mistake with MariaDB and RabbitMQ https://review.opendev.org/c/openstack/openstack-ansible/+/949733 15:14:38 I had one patch which was a bug fix, but can break the behaviour: 15:14:41 #link https://review.opendev.org/c/openstack/openstack-ansible-os_trove/+/950491 15:15:06 which potentially might be a good fit for the Epoxy 15:21:30 Other important topic EL10 15:21:41 I had not time last week to start working on it :( 15:22:24 But apparently, I need to start it sooner then later 15:22:49 not sure if there was any related progress on infra side of things though 15:27:17 Merged openstack/openstack-ansible master: 2025.1 (Epoxy) Release Candidate - fix for year https://review.opendev.org/c/openstack/openstack-ansible/+/950739 15:28:28 Actually, about docs 15:28:53 I am thinking, if we should give up maintaining whole history of releases for our `latest` release 15:29:07 #link https://docs.openstack.org/openstack-ansible/latest/ 15:30:15 and just leave "current" one or none at all, just doc tree 15:32:16 as current one not only need maintenance, but also needs translators to update each cycle 15:32:25 do we end up having to go and fix that page for all the branches as the status of things changes? 15:32:44 yup 15:32:52 or well 15:33:02 for all branches we have a different version of it 15:33:13 ie https://docs.openstack.org/openstack-ansible/2024.2/ 15:33:19 yes i was just looking and its a little random 15:33:53 it really is 15:34:07 and 2024.2 is an outstanding example 15:34:27 and 2025.1 needs to be patched.... 15:36:40 But I'd guess I'd align latest to the state of https://docs.openstack.org/openstack-ansible/2024.1/ 15:36:43 or smth like that 15:42:33 Also, 2023.2 was EOL-ed for projects 15:42:50 so EOL-ing of roles were proposed 15:42:52 #link https://review.opendev.org/c/openstack/releases/+/948217 15:43:10 With that I've also proposed to drop upgrade jobs for 2024.1 15:43:30 as eventually unmaintained branch would not exist 15:43:37 yes 15:43:59 i hope that soon some of the fixes we have done in recent branches will be trickling down to the new unmaintained ones 15:44:16 it might now finally be possible to have some CI work on those without terrible difficulty 15:45:53 Does this include upgrade jobs? 15:46:20 As while there were improvements for respecting unmaintained branch, non-SLURP go straight to EOL 15:46:20 i did do some work on making it better at picking the N-1 branch name 15:46:37 and I can't recall we did anything to cover that 15:46:38 and i think if the branch is deleted it should pick a previous one 15:47:00 hu 15:47:14 but then we still would need to be dropping upgrade from previous SLURP 15:47:24 as we'd be testing same thing twice? 15:47:30 https://github.com/openstack/openstack-ansible/blob/master/scripts/gate-check-commit.sh#L69 15:48:02 yeah, but this selects `stable` vs `unmaintained`? 15:48:05 right yes so that automatically sorts out "stable/" vs "unmaintained", we'd still need to fix line 68 15:48:49 but now we kinda want to have $UPGRADE_SOURCE_RELEASE-eol ? 15:48:59 if neither nor exist? 15:49:14 hmm yes you are right 15:49:28 which is a bit /o\ but yeah... 15:50:21 if we can feed in UPGRADE_SOURCE_BRANCH from outside then all that logic is bypassed 15:50:31 which could turn out to be the simplest 15:53:41 True, but then we'd still need to do update of zuul jobs 15:54:01 which we probably have to do anyway 15:56:26 hrrm it is messy 15:56:33 as we still want to run these locally 15:56:48 true... 15:57:56 so if the branch prefix is empty, the branch does not exist 15:58:10 then we can assume it is -eol ? 15:59:48 Yeah, I think we can... 16:00:15 that sounds like reasonable assumption... 16:00:58 #endmeeting