15:00:19 <noonedeadpunk> #startmeeting openstack_ansible_meeting 15:00:19 <opendevmeet> Meeting started Tue Aug 22 15:00:19 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:19 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:19 <opendevmeet> The meeting name has been set to 'openstack_ansible_meeting' 15:00:24 <noonedeadpunk> #topic rollcall 15:00:25 <NeilHanlon> o/ hi 15:00:25 <noonedeadpunk> o/ 15:02:43 <damiandabrowski> hi! 15:04:15 <noonedeadpunk> #topic office hours 15:04:42 <noonedeadpunk> I think right now we have ourself unblocked 15:04:54 <noonedeadpunk> Except adjutant and senlin roles that are failing upgrades 15:05:24 <noonedeadpunk> So we need to define what we wanna merge for Antelope for 27.1.0 release 15:05:44 <NeilHanlon> is my sanity available for merge? i seem to have lost it 15:06:05 <noonedeadpunk> huh? not sure what's that :( 15:06:34 <NeilHanlon> joking about me being a bit crazy lately lol 15:07:03 <noonedeadpunk> ah lol 15:07:26 <noonedeadpunk> I can totally realate to that, as pretty much things are going on right now 15:08:28 <noonedeadpunk> For 2023.1 releasing, I think the most thing we might want to wait for - is keystone patch 15:08:44 <noonedeadpunk> #link https://review.opendev.org/c/openstack/keystone/+/891521 15:08:48 <noonedeadpunk> and then it's backport 15:09:22 <noonedeadpunk> As I guess from our side we've backported (maybe not merged on 2023.1 but at least on master) everything we wanted 15:12:33 <noonedeadpunk> For fixing adjutant we need to bump Zed SHAs, then it will fix atnelope upgrade jobs and allow to merge antelope patches 15:12:44 <damiandabrowski> yup, at least all my patches are already merged to 2023.1 which is pretty awesome 15:13:10 <noonedeadpunk> for senlin - I;m going to check why it's failing in aio. As it's db upgrade that fails in jobs 15:13:44 <noonedeadpunk> regarding db upgrade - it seems we're missing online upgrade command for placement 15:14:20 <noonedeadpunk> has started working on that https://review.opendev.org/c/openstack/openstack-ansible-os_placement/+/892159 15:15:00 <noonedeadpunk> Then let's move to discussing current development 15:15:16 <noonedeadpunk> Ansible-core 2.15 is about to pass this time 15:15:18 <noonedeadpunk> #link https://review.opendev.org/c/openstack/openstack-ansible/+/886527 15:15:29 <noonedeadpunk> We still need some patches to land that are fixing linters 15:15:43 <noonedeadpunk> (and I guess bringing bugs) 15:17:02 <noonedeadpunk> then as a follow-up to discussion regarding TLS performance degradation - I've pushed a patch that proposes to enable http/2 when TLS is enabled on all backends 15:17:29 <noonedeadpunk> though it also capable of enabling http/2 only when there is no TLS 15:17:33 <noonedeadpunk> #link https://review.opendev.org/q/topic:osa/h2 15:21:24 <noonedeadpunk> I guess having HTTP/2 without TLS is quite arguable decision 15:21:35 <noonedeadpunk> Though I'm not sure we should prevent anyone from doing that 15:22:06 <noonedeadpunk> But I kinda wonder if we might want to split these variables to enable http/2 only for TLS and for non-tls 15:23:07 <noonedeadpunk> Or do that just for TLS, given that redirects and stuff are not covered anyway 15:23:13 <damiandabrowski> i was going to suggest that, as most browsers support HTTP/2 only over TLS 15:23:18 <NeilHanlon> that's a tricky one, yeah 15:23:32 <damiandabrowski> https://www.haproxy.com/documentation/hapee/latest/load-balancing/protocols/http-2/#:~:text=Most%20browsers%20support%20HTTP/2%20over%20HTTPS%20only%2C%20but%20you%20may%20find%20it%20useful%20to%20enable%20h2c%20between%20backend%20services%20(e.g.%20gRPC%20services) 15:25:09 <noonedeadpunk> I was actually thinking for consistency between behaviour for frontends and backends 15:26:50 <damiandabrowski> and backends? do they support http/2? 15:27:15 <noonedeadpunk> not openstack backends 15:27:36 <noonedeadpunk> but role is kinda used outside of openstack as well 15:27:46 <noonedeadpunk> well, ok. 15:27:51 <noonedeadpunk> then let's simplfy 15:28:03 <noonedeadpunk> we use http/2 for frontends only if TLS is enabled 15:28:20 <noonedeadpunk> for backends - we rely on `haproxy_backend_h2`? 15:28:33 <damiandabrowski> sounds good for me 15:29:13 <noonedeadpunk> ok, will update patches then 15:29:28 <damiandabrowski> or maybe we can skip haproxy_backend_h2 because it can be passed in backend args? 15:29:33 <noonedeadpunk> and maybe even limit to a single patch and default `haproxy_frontend_h2` to True? 15:30:53 <damiandabrowski> ah yes, alpn should do the job then 15:33:36 <noonedeadpunk> then we have openstack_resources role that is finally passing 15:33:38 <noonedeadpunk> https://review.opendev.org/q/topic:osa%252Fopenstack_resources 15:33:49 <noonedeadpunk> it seems, that even octavia migration is done accurately 15:34:24 <noonedeadpunk> what I don't really like about that (octavia compatibility), that new deployments will be messed up with a short rsa key and old algo... 15:36:37 <noonedeadpunk> not sure what to do about that though 15:37:06 <noonedeadpunk> don't really want to implement a variable that needs to be overriden on upgrade, but probably that's smth worth actually doing 15:47:39 <opendevreview> Dmitriy Rabotyagov proposed openstack/openstack-ansible master: Fix linters to satisfy ansible-lint 6.18 https://review.opendev.org/c/openstack/openstack-ansible/+/886527 15:51:36 <opendevreview> Dmitriy Rabotyagov proposed openstack/openstack-ansible master: Bump ansible-core to 2.15.3 and ansible-lint https://review.opendev.org/c/openstack/openstack-ansible/+/892371 15:52:11 <opendevreview> Damian Dąbrowski proposed openstack/openstack-ansible stable/2023.1: Gather facts before including common-playbooks https://review.opendev.org/c/openstack/openstack-ansible/+/889023 15:53:06 <damiandabrowski> ahhh, I missed this change: https://review.opendev.org/c/openstack/openstack-ansible/+/889023 15:53:11 <damiandabrowski> for sure it needs to land before 27.1.0 :D 15:54:05 <opendevreview> Dmitriy Rabotyagov proposed openstack/openstack-ansible master: Bump ansible collection versions https://review.opendev.org/c/openstack/openstack-ansible/+/892373 15:54:47 <noonedeadpunk> damiandabrowski: you can't apply depends-on to another branch 15:54:58 <noonedeadpunk> or well. it will unlikely get merged like that iirc 15:55:19 <noonedeadpunk> but yes, good point that we'd need that 15:55:36 <damiandabrowski> awww thanks, i completely missed that these 2 changes are in different branches :D 15:55:43 <opendevreview> Damian Dąbrowski proposed openstack/openstack-ansible stable/2023.1: Gather facts before including common-playbooks https://review.opendev.org/c/openstack/openstack-ansible/+/889023 15:56:16 <noonedeadpunk> so the summury of what's waiting to land for 2023.1 is here 15:56:21 <noonedeadpunk> #link https://review.opendev.org/q/parentproject:openstack/openstack-ansible+branch:%255Estable/2023.1+status:open+ 15:56:46 <noonedeadpunk> and yeah, I disk full is another good topic to cover 15:56:57 <noonedeadpunk> so this happens due to the bug in ovs itself 15:57:24 <noonedeadpunk> it has been resolved for quite a while though, but rdo has stopped building ovs 2.17 15:57:43 <noonedeadpunk> so we either need let major upgrade of ovs to happen for stable branches 15:57:48 <noonedeadpunk> or trimm logs. 15:57:56 <noonedeadpunk> not sure what's best tbg... 15:58:09 <noonedeadpunk> trimming logs kinda make sense to me regardelss 15:58:37 <noonedeadpunk> but maybe we should also let stable branches to get latest ovs that's supplied by rdo for the branch.... 15:59:21 <noonedeadpunk> as it's probably also not best solution from security prespective to stick with old unmaintained version for too long... 15:59:55 <damiandabrowski> i'm ok with both solutions 16:01:36 <noonedeadpunk> #endmeeting