15:00:37 <noonedeadpunk> #startmeeting openstack_ansible_meeting
15:00:37 <opendevmeet> Meeting started Tue Jul  4 15:00:37 2023 UTC and is due to finish in 60 minutes.  The chair is noonedeadpunk. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:37 <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:42 <noonedeadpunk> #topic rollcall
15:01:11 <damiandabrowski> hi!
15:02:44 <noonedeadpunk> o/
15:02:55 * noonedeadpunk feel quite bad, so let's make this quickly
15:03:03 <noonedeadpunk> #topic office hours
15:03:40 <noonedeadpunk> I;ve proposed SHA bump for 27.0.1 here: https://review.opendev.org/c/openstack/openstack-ansible/+/887513
15:03:56 <noonedeadpunk> It should cover couple of nasty bugs we've been reported
15:04:14 <noonedeadpunk> I saw you damiandabrowski found what's wrong with rally
15:04:35 <noonedeadpunk> But I've just commented on the patch, as it's lightly more tricky then you think
15:07:05 <noonedeadpunk> For previous week I had some progress on ansible-core 2.15: https://review.opendev.org/c/openstack/openstack-ansible/+/886527
15:07:16 <noonedeadpunk> I think it's blocked now with erlang version for rhel
15:07:53 <damiandabrowski> i proposed a patch to fix erlang/rabbitmq issues: https://review.opendev.org/c/openstack/openstack-ansible-rabbitmq_server/+/887592
15:10:54 <noonedeadpunk> do we want to do the same with rabbit as well?
15:11:25 <noonedeadpunk> as rabbit bugfix version is quite a deal I would say
15:11:49 <noonedeadpunk> historically, they can apply different requirements to these
15:11:55 <noonedeadpunk> check this out https://www.rabbitmq.com/which-erlang.html
15:12:16 <damiandabrowski> yeah, i linked this page in the commit message
15:12:35 <damiandabrowski> and rabbit is affected by the same issue as erlang so i think we need to do this for both
15:12:47 <noonedeadpunk> Like 3.10.7 can be used with erlang 23.2, then 3.10.13 requires 24.2
15:12:56 <damiandabrowski> my commit msg explains why
15:13:22 <damiandabrowski> "I don't think that pinning to specific patch version (number afer second dot) is really needed because according to [2],
15:13:28 <damiandabrowski> rabbitmq 3.11.X should always work with erlang 25.3.Y. Based on that information, it is enough to pin rabbitmq-server==3.11.* and erlang==25.3.*"
15:14:59 <damiandabrowski> other OSA versions may not apply to this logic, but for master and stable/2023.1 we are only talking about compatibility between rabbitmq 3.11 and erlan 25.3
15:15:17 <noonedeadpunk> It's *now* tomorrow they might start requiring erlang 26.1.0 with 3.11.25, for example
15:15:33 <damiandabrowski> yes, but then we'll need to edit package versions anyway
15:15:44 <noonedeadpunk> um, why so?
15:15:59 <noonedeadpunk> and what about existing deployments?
15:16:30 <damiandabrowski> because now we pin erlang 25 not 26
15:16:49 <damiandabrowski> so what WILL happen in erlang 26 does not affect us at all
15:16:56 <noonedeadpunk> which is absolutely fine if we won't have wildcard applied to rabbit
15:17:00 <damiandabrowski> if we decide to bump erlang to 26, we should review compatibility versions
15:17:29 <noonedeadpunk> but if we apply wildcard - rabbit just fail with older erlang?
15:17:53 <noonedeadpunk> until we update erlang version
15:18:05 <damiandabrowski> there's no way it can fail as the proposed versions are always compatible with each other
15:18:15 <damiandabrowski> rabbit 3.11.* and erlang 25.3.*
15:18:36 <noonedeadpunk> And how about my example about 3.10.7 and 3.10.8 ?
15:18:55 <noonedeadpunk> What makes you sure it won't happen again anytime soon?
15:19:23 <noonedeadpunk> just with 3.11 and 25.3 vs 26.1
15:19:45 <noonedeadpunk> or I'm missing smth obvious here?
15:21:25 <damiandabrowski> hmm i don't know if they can do something like that with 3.11 if 3.12 is already available
15:21:43 <damiandabrowski> (by "i don't know" i really mean that i don't know, i'm not suggesting they won't do that :D)
15:21:53 <damiandabrowski> but current behavior also sucks, especially for ubuntu
15:22:16 <damiandabrowski> because we just define preferred version
15:22:41 <damiandabrowski> so for ex. if preferred rabbitmq version is not available, latest one will be installed
15:22:55 <noonedeadpunk> Well, 3.10.13 was released after 3.11.0 from what I see
15:23:06 <damiandabrowski> which IMO is even worse than rocky behavior that just fails
15:23:16 <noonedeadpunk> where they've jumped from 24.2 to 24.3
15:24:35 <noonedeadpunk> 3.11.0 was released Sep 26, 2022, 3.10.13 on Dec 13, 2022
15:24:39 <damiandabrowski> i think i'll need to spend more time on this compatibility matrix to share some wise thoughts
15:24:42 <damiandabrowski> but i get your point now
15:25:04 <noonedeadpunk> I fully agree about ubuntu behaviour though
15:25:33 <noonedeadpunk> maybe we should specify version to the package name like we do with rocky, rather then set pinning
15:25:46 <noonedeadpunk> to fail rather then isntall smth
15:27:10 <damiandabrowski> anyway, i don't want to take to much of your time today if you're not feeling well, we can discuss it tomorrow or later this week
15:27:13 <damiandabrowski> i'll also prepare better
15:27:17 <noonedeadpunk> would be awesome to unblock gates and then indeed invest time into proper thinking
15:27:48 <noonedeadpunk> I guess stable branches are not affected yet?
15:28:17 <damiandabrowski> i think stable/2023.1 has to be affected
15:28:47 <noonedeadpunk> we're using erlang 25.2.3 there
15:29:09 <noonedeadpunk> vs 25.3.2 on master
15:29:39 <noonedeadpunk> https://review.opendev.org/c/openstack/openstack-ansible/+/887513 passed today though...
15:29:42 <damiandabrowski> ahhh i didn't notice it
15:30:05 <damiandabrowski> i can check it quickly to make sure, 1sec
15:30:07 <noonedeadpunk> but not sure, maybe also worth applying same logic there
15:31:26 <damiandabrowski> yeah, 25.2.3-1 works fine on my test r9 VM
15:31:59 <noonedeadpunk> I feel it will break soon though....
15:32:01 <damiandabrowski> but this novemberain.com mirror is super slow(at least for me) :/
15:32:24 <noonedeadpunk> well, we have what we have
15:32:56 <noonedeadpunk> anything else we wanna talk about?
15:33:51 <damiandabrowski> i just want to highlight, that if everyone agrees that we want to keep TLS disabled by default on backend and internal VIPs, my changes are waiting for reviews
15:33:53 <damiandabrowski> https://review.opendev.org/q/topic:tls-backend+status:open
15:34:34 <noonedeadpunk> will review them, but not today....
15:34:45 <noonedeadpunk> Also we should fix gates first anyway
15:35:14 <noonedeadpunk> (so don't but +W anywhere until they're fixed)
15:35:18 <noonedeadpunk> *put
15:35:23 <damiandabrowski> ack
15:36:37 <noonedeadpunk> #endmeeting