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