15:00:38 <noonedeadpunk> #startmeeting openstack_ansible_meeting
15:00:38 <opendevmeet> Meeting started Tue Nov 12 15:00:38 2024 UTC and is due to finish in 60 minutes.  The chair is noonedeadpunk. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:38 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:38 <opendevmeet> The meeting name has been set to 'openstack_ansible_meeting'
15:00:45 <noonedeadpunk> #topic rollcall
15:00:47 <noonedeadpunk> o/
15:01:06 <mgariepy> hey
15:01:14 <mgariepy> been a while
15:01:39 <noonedeadpunk> indeed! hope all is well
15:02:41 <mgariepy> yep everything is going well :)
15:02:50 <mgariepy> how about you?
15:03:07 <noonedeadpunk> a bit /o\ with everything going on
15:03:19 <noonedeadpunk> but overall things are moving at least
15:04:03 <jrosser> o/ hello
15:04:50 <opendevreview> Dmitriy Rabotyagov proposed openstack/openstack-ansible-plugins master: Move healthcheck playbooks to collection  https://review.opendev.org/c/openstack/openstack-ansible-plugins/+/933610
15:04:50 <noonedeadpunk> #topic office hours
15:05:13 <noonedeadpunk> So, mariadb 11.4 is pretty much ready
15:05:29 <noonedeadpunk> I still had to disable TLS verification, but it affects only mariabackup
15:05:54 <noonedeadpunk> #link https://review.opendev.org/c/openstack/openstack-ansible-galera_server/+/922377/12/templates/cluster.cnf.j2
15:06:50 <noonedeadpunk> regarding rabbitmq 4.0 - I somehow thought that we're using 3.13 for 2024.1 :(
15:07:12 <noonedeadpunk> #link https://review.opendev.org/c/openstack/openstack-ansible-rabbitmq_server/+/934060
15:07:34 <noonedeadpunk> but it's indeed 3.12 :(
15:08:30 <noonedeadpunk> I was thinking it was part of 2024.1 but it's not https://review.opendev.org/c/openstack/openstack-ansible-rabbitmq_server/+/922378
15:08:40 <noonedeadpunk> so I wonder what are we gonna do with that...
15:08:56 <noonedeadpunk> as this means - we can't have 4.0 for 2025.1 then as well
15:11:32 <andrewbonney> I hadn't thought about SLURP impact on RMQ version jumps. That's not ideal
15:12:24 <mgariepy> 3.13 is EOL as of now for community release
15:12:44 <noonedeadpunk> well, community is supporting always only current release nowdays
15:13:08 <noonedeadpunk> so we can't always be on latest for stable branches anyway
15:13:47 <noonedeadpunk> So eventually we either need to wait for 2025.2 for 4.0, or backport 3.13 to 2024.1 and write a release note with requirement of minor upgrade before proceeding
15:13:56 <noonedeadpunk> neither are ideal to say the least
15:14:28 <andrewbonney> If we wait for 4.0 it feels like there's a risk of getting way behind, subject to RMQ's release cadence
15:18:35 <mgariepy> A pre-step to upgrade rabbit on 2024.1 for SLURP to 2025.1 isn't too bad IMO.
15:18:55 <noonedeadpunk> probably it's a lower risk indeed...
15:19:11 <noonedeadpunk> bad we realized this after getting 29.1.0 out though
15:19:21 <noonedeadpunk> but we pushed it out not too far ago
15:19:32 <andrewbonney> Could we add any automation to step through major versions from current to target, or does that feel awkward? Feels like this may come up again in future
15:20:57 <noonedeadpunk> I'd say it's indeed quite awkward... While it could be possible, I'm not sure we want to have such complexity in code
15:21:10 <andrewbonney> Fair enough
15:21:30 <noonedeadpunk> as we have a check for current rabbitmq version. so we can add another upgrade loop somehow... somewhere...
15:21:58 <noonedeadpunk> but it should be on playbook level anyway I assume
15:22:03 <noonedeadpunk> not on a role level
15:22:20 <noonedeadpunk> so it will be not neat at all
15:26:50 <noonedeadpunk> but I think indeed that bumping rabbitmq version for 2024.1 might be best option now.
15:27:05 <noonedeadpunk> but then there will be 2 concenring things with 4.0
15:27:20 <noonedeadpunk> first - quorum queues requirement, and second 3.13 requirement.
15:27:38 <noonedeadpunk> none of them are critical to have that said
15:28:13 <noonedeadpunk> I will push patch to 2024.1 I guess and some release notes supporting this requirement
15:28:36 <noonedeadpunk> I also wrote some doc around how I was doing pretty endpoint names
15:28:43 <noonedeadpunk> #link https://review.opendev.org/c/openstack/openstack-ansible/+/934536
15:29:35 <andrewbonney> noonedeadpunk: I think if backporting 3.13 we'll also need Idb5c02109458771853e0fdbc7f6bb27beaa731b4, otherwise broken experimental feature flags will get enabled
15:30:31 <andrewbonney> See 'khepri_db' in https://www.rabbitmq.com/docs/upgrade
15:32:48 <NeilHanlon> o/ way late, sry. triple double booked today because of timezone fun 🙃
15:33:15 <noonedeadpunk> andrewbonney: I thought you wanted to link another patch, but I see what you mean
15:33:32 <noonedeadpunk> I thought that's also in 2024.1 though :D
15:36:51 <mgariepy> we also need to make sure that the rabbitmq validate the version before upgrade in case older branch of 2024.1 was deployed and not upgraded before the SLURP to 2025.1
15:37:08 <noonedeadpunk> that is a very good point
15:44:19 <noonedeadpunk> and we can fail with meaningfull error if we can't
15:44:25 <noonedeadpunk> upgrade
15:48:31 <mgariepy> before the cluster is screwed :D hahha
15:49:03 <noonedeadpunk> preferably "D
15:49:20 <noonedeadpunk> and we're less then 1 month until final release
15:50:15 <noonedeadpunk> we also have quite some outstanding reviews
16:00:17 <noonedeadpunk> #link http://bit.ly/osa-review-board-v5
16:00:22 <noonedeadpunk> #endmeeting