15:01:08 <noonedeadpunk> #startmeeting openstack_ansible_meeting
15:01:08 <opendevmeet> Meeting started Tue Sep 24 15:01:08 2024 UTC and is due to finish in 60 minutes.  The chair is noonedeadpunk. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:08 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:08 <opendevmeet> The meeting name has been set to 'openstack_ansible_meeting'
15:01:11 <noonedeadpunk> #topic rollcall
15:01:17 <NeilHanlon> o/
15:01:19 <noonedeadpunk> o/ hey Neil!
15:01:25 <damiandabrowski> hi!
15:02:25 <NeilHanlon> hi damiandabrowski, noonedeadpunk :)
15:05:19 <opendevreview> Dmitriy Rabotyagov proposed openstack/openstack-ansible-os_horizon master: Link plugin settings extension separately  https://review.opendev.org/c/openstack/openstack-ansible-os_horizon/+/930346
15:05:19 <noonedeadpunk> #topic office hours
15:05:29 <noonedeadpunk> so, we do have bunch of things for review
15:05:40 <noonedeadpunk> and our gates on master are blocked by this: https://review.opendev.org/c/openstack/openstack-ansible-openstack_hosts/+/930272
15:06:55 <NeilHanlon> +2 from me :) (and the W+1)
15:07:03 <noonedeadpunk> nice, thanks a lot!
15:07:17 <noonedeadpunk> we also got quite some bug reports this week already
15:07:38 <noonedeadpunk> I was trying to go through them, but facing more and more nits along the way
15:09:22 <noonedeadpunk> I think https://review.opendev.org/c/openstack/openstack-ansible-os_neutron/+/929549 was one of latest backports to 2024.1 I wanted to have before making a release
15:09:42 <noonedeadpunk> ah, and ofc https://review.opendev.org/q/topic:%22osa/apache_mpm_alignment%22 is quite a topic on itself
15:10:22 <noonedeadpunk> but it kinda is also needs to be backported..
15:10:31 <NeilHanlon> fun...
15:10:37 <noonedeadpunk> as on metal they do conflict, esp if skyline is in
15:11:46 <opendevreview> Dmitriy Rabotyagov proposed openstack/openstack-ansible-os_horizon master: Link plugin settings extension separately  https://review.opendev.org/c/openstack/openstack-ansible-os_horizon/+/930346
15:11:58 <opendevreview> Dmitriy Rabotyagov proposed openstack/openstack-ansible-os_horizon master: Link plugin settings extension separately  https://review.opendev.org/c/openstack/openstack-ansible-os_horizon/+/930346
15:12:17 <noonedeadpunk> and with that new release is coming rapidly
15:14:56 <opendevreview> Dmitriy Rabotyagov proposed openstack/openstack-ansible-os_neutron master: Define default value for `neutron_default_availability_zones`  https://review.opendev.org/c/openstack/openstack-ansible-os_neutron/+/930265
15:15:35 <NeilHanlon> yep yep
15:15:57 <noonedeadpunk> there's also an update regarding mariadb 11.4 - the issue where we'd had to issue SSL cert for localhost was fixed upstream
15:16:15 <noonedeadpunk> So it should be in the next release
15:16:22 <noonedeadpunk> though, I don't know when it will be :(
15:17:03 <noonedeadpunk> to be specific - in 11.4.4
15:18:16 <NeilHanlon> at least it's being fixed :)
15:19:22 <NeilHanlon> on rocky mirrors: I met again w/ infra group last week and presented some findings--result of which is I will put in a Change to setup the sync for Rocky mirrors and then work with infra to get an afs share/quota configured
15:19:40 <noonedeadpunk> ok, that is a nice update
15:20:12 <noonedeadpunk> I haven't seen Rocky specific failures due to mirrors last week, fwiw
15:20:28 <noonedeadpunk> so it seems they've improved a lot since ... winter?
15:20:55 <NeilHanlon> if my theory is correct, there should be some failures in a day or so once we release a batch of updates RH put out last night
15:23:19 <noonedeadpunk> I also had some fun with OVN and Neutron lately, found 1000x regression in performance, which also affected Nova listings
15:23:45 <noonedeadpunk> fix for that landed yesterday for neutron and backports were proposed as well.
15:24:12 <NeilHanlon> ouch!
15:24:34 <noonedeadpunk> #link https://review.opendev.org/c/openstack/neutron/+/929941
15:24:54 <noonedeadpunk> And I do recall someone coming to IRC with question about performance regression after upgrade
15:24:57 <noonedeadpunk> so here we are...
15:26:18 <jrosser> o/ hello
15:26:24 <opendevreview> Dmitriy Rabotyagov proposed openstack/openstack-ansible-rabbitmq_server master: Map all relevant architectures for deb822 repository setup  https://review.opendev.org/c/openstack/openstack-ansible-rabbitmq_server/+/930283
15:30:21 <noonedeadpunk> jrosser: where we are with moving playbooks to collections?
15:30:26 <noonedeadpunk> only services are left?
15:30:43 <jrosser> ah yes, i have not yet managed to look at the remainder
15:30:55 <jrosser> openstack services would indeed be the next thing to do
15:31:01 <jrosser> which will leave some leftovers i think
15:32:06 <opendevreview> Dmitriy Rabotyagov proposed openstack/openstack-ansible master: Fix upgrade job on master to upgrade from 2024.1 to master  https://review.opendev.org/c/openstack/openstack-ansible/+/928771
15:32:18 <noonedeadpunk> ok, I can look into that I guess
15:34:31 <noonedeadpunk> once CI is unblocked I wanna take another look at SHA bump failres on master
15:34:44 <noonedeadpunk> and potentially switch things to stable branches to track them
15:36:03 <jrosser> what is left to make a release on Caracal?
15:36:12 <jrosser> do you want to get the mpm stuff backported for that?
15:36:51 <noonedeadpunk> I think so...
15:36:57 <noonedeadpunk> as that is quite breaking change
15:37:05 <noonedeadpunk> and very unpleasant issue to deal with
15:37:28 <noonedeadpunk> and also https://review.opendev.org/c/openstack/openstack-ansible-os_neutron/+/929549
15:37:33 <noonedeadpunk> I think that's all
15:37:50 <noonedeadpunk> I don't know anything else which should be considered as critical for upgrade
15:40:50 <noonedeadpunk> especially with recent neutron backports :)
15:41:18 <noonedeadpunk> as our 29.1.0 is smth I'd consider minorly upgrading to, hehe
15:41:28 <noonedeadpunk> (is going to be)
15:42:21 <noonedeadpunk> damiandabrowski: it would be also nice if you could spend some time on reviews this week
15:42:33 <damiandabrowski> okok, i will!
15:44:57 <noonedeadpunk> ah - actually this patch is potentially a point for discussion: https://review.opendev.org/c/openstack/openstack-ansible/+/929775
15:45:02 <noonedeadpunk> #link https://review.opendev.org/c/openstack/openstack-ansible/+/929775
15:45:23 <noonedeadpunk> while it kind of make sense - I think it's might be better to patch haproxy
15:46:28 <noonedeadpunk> is there reason why we define SSL for `bind` if haproxy_balance_type is tcp?
15:46:30 <noonedeadpunk> #link https://opendev.org/openstack/openstack-ansible-haproxy_server/src/branch/master/templates/service.j2#L56
15:47:10 <jrosser> the commit message is not helping me much there
15:47:16 <jrosser> were is this user certificate?
15:47:56 <noonedeadpunk> if I'm not mistaken - it's about like any certificate
15:48:30 <jrosser> can't you put sometimes tls on the console service itself
15:48:47 <jrosser> and then this patch talks about haproxy, which is another place there could be a certficate
15:49:08 <noonedeadpunk> I think what they are into is this
15:49:41 <noonedeadpunk> #link https://zuul.opendev.org/t/openstack/build/a4616d160b9249289a16b5980bf3e58a/log/logs/etc/host/haproxy/conf.d/nova_novnc_console.txt#6
15:50:16 <noonedeadpunk> or well
15:51:34 <noonedeadpunk> #link https://opendev.org/openstack/openstack-ansible/src/branch/master/inventory/group_vars/nova_all/haproxy_service.yml#L19-L20
15:51:54 <jrosser> this is complicated
15:51:58 <noonedeadpunk> so if they do define `nova_console_user_ssl_cert` - they don't want haproxy to be configured with TLS
15:52:04 <jrosser> as there is compute hosts <> novnc proxy
15:52:12 <jrosser> novnc proxy <> haproxy
15:52:17 <jrosser> and haproxy <> user
15:52:48 <jrosser> and afaik we have have tls in all of those places
15:52:51 <noonedeadpunk> yes, true, but then we do have `haproxy_nova_console_http_mode | ternary('http', 'tcp')`
15:53:07 <noonedeadpunk> so if there's a `tcp` - we should not be adding TLS to BIND
15:53:38 <noonedeadpunk> I don't think it will matter or terminate TLS on haproxy at all
15:53:56 <noonedeadpunk> but having `ssl` statement on bind is confusion
15:54:08 <noonedeadpunk> I'm not 100% sure if I got it correctly
15:54:14 <noonedeadpunk> as you said - it's really complicated
15:54:33 <noonedeadpunk> and I personally can hardly asses what is intented behaviour here in fact
15:56:00 <jrosser> no i am not able to make a clear understanding of the actual issue without much more thought
15:57:10 <noonedeadpunk> but what I'm into - is that probably having ssl defined in haproxy when `mode tcp` doesn't make sense?
15:58:24 <noonedeadpunk> as my guess was that it's the thing which is confusing
15:58:46 <jrosser> i think that we might have really old code here for the user_cert stuff
15:59:11 <jrosser> like here https://opendev.org/openstack/openstack-ansible-os_nova/src/branch/master/tasks/consoles/nova_console_novnc_ssl.yml
15:59:27 <noonedeadpunk> oh, wow, yes
16:00:03 <noonedeadpunk> it might work though
16:00:26 <noonedeadpunk> but doesn't make much sense indeed
16:01:31 <jrosser> i don't know why this is not covered by the pki role
16:01:44 <jrosser> as i do think that james worked specifically on tls for the consoles
16:02:00 <jrosser> and those vars are not in defaults/main.yml for the nova role either
16:02:54 <noonedeadpunk> yep, seems like leftover which needs to be covered as well
16:03:10 <noonedeadpunk> so good patch from standpoint of raising attention at least
16:04:31 <noonedeadpunk> #endmeeting