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