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