15:00:18 <noonedeadpunk> #startmeeting openstack_ansible_meeting
15:00:18 <opendevmeet> Meeting started Tue Apr 11 15:00:18 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:18 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:18 <opendevmeet> The meeting name has been set to 'openstack_ansible_meeting'
15:00:26 <noonedeadpunk> #topic rollcall
15:00:28 <noonedeadpunk> o/
15:00:47 <damiandabrowski> hey!
15:03:12 <NeilHanlon> o/ hey folks
15:03:54 <noonedeadpunk> #topic office hours
15:03:56 <mgariepy> half there as usual :D
15:04:32 <noonedeadpunk> So, seems we have couple of broken things lately.
15:04:49 <noonedeadpunk> mainly due to collection version bump
15:05:02 <jrosser> o/ hello
15:05:23 <noonedeadpunk> 1. Heat role should be fixed with https://review.opendev.org/c/openstack/openstack-ansible-plugins/+/880028
15:06:04 <noonedeadpunk> 2. trove/designate at very least - this topic covers it https://review.opendev.org/q/topic:osa%252Fansible-collection-2
15:06:21 <noonedeadpunk> 3. We have weirdly broken Octavia - have close to no idea what's wrong with it
15:07:59 <jrosser> broken centos functional job on 880028 as well
15:08:09 <jrosser> more gpg fun by the look of it
15:09:06 <noonedeadpunk> well. we've disabled centos lxc jobs for $reason, but that didn't touch functional ones
15:09:15 <noonedeadpunk> likely this should be just patched or dunno
15:09:22 <noonedeadpunk> (and replaced with rocky)
15:09:59 <noonedeadpunk> I'm quite afraid to touch tests repo for that
15:10:28 <noonedeadpunk> On the good side - overall role health look decent accourding to this series of patches https://review.opendev.org/q/topic:osa/systemd_restart_on_unit_change
15:10:45 <noonedeadpunk> Ah, forgot.
15:11:14 <noonedeadpunk> 4. Adjutant has backported django version fix, so we should start merging patches since Y to fix upgrade jobs
15:12:32 <noonedeadpunk> But Octavia is the most concerning at the moment from all
15:13:16 <noonedeadpunk> We also had some progress on landing haproxy stuff
15:14:12 <damiandabrowski> regarding haproxy & internal-tls i have two things for today
15:14:23 <damiandabrowski> 1. https://review.opendev.org/c/openstack/openstack-ansible/+/879791/
15:14:23 <damiandabrowski> openstack_haproxy_horizon_stick_table vs. horizon_haproxy_stick_table vs. haproxy_horizon_stick_table
15:14:50 <noonedeadpunk> I was just looking at this one
15:14:52 <damiandabrowski> 2. do we still need this for Z-> A upgrade? https://opendev.org/openstack/openstack-ansible/commit/befd8424e2efd4e1bebe89b5085032bf120de148
15:14:53 <jrosser> we should not keep changing var names
15:15:12 <jrosser> they're like fixed, really, unless it's really really needing changing
15:16:19 <damiandabrowski> regarding var name, i don't really mind if we change it or not.
15:16:50 <damiandabrowski> regarding upgrade process: after we implemented haproxy base service, we probably need to run haproxy-install.yml normally(in setup-infrastucture.yml): https://review.opendev.org/c/openstack/openstack-ansible/+/880058
15:17:01 <noonedeadpunk> I tend to agree here, I don't really see necessity in renaming. At very least, if we want to rename we'd better introduce deprecation of old one and then drop after couple of releases
15:17:49 <noonedeadpunk> So at very least, I'd assume heaving `haproxy_stick_table: "{{ openstack_haproxy_horizon_stick_table| default(horizon_haproxy_stick_table) }}"`
15:17:50 <jrosser> why does horizon affect tempest?
15:18:35 <damiandabrowski> jrosser: https://opendev.org/openstack/openstack-ansible/src/branch/master/tests/roles/bootstrap-host/templates/user_variables_horizon.yml.j2#L17
15:19:00 <jrosser> oh well that would do it :)
15:20:09 <noonedeadpunk> regarding upgrade, I think that with separated config, we can revert that
15:20:51 <noonedeadpunk> IIRC there was a bug, that haproxy was re-configuring galera backend, making it fully unavailable until run of galera role
15:21:00 <damiandabrowski> okok thanks, i'll check it
15:21:01 <noonedeadpunk> well, not a bug, but upgrade issue
15:21:25 <damiandabrowski> was just curious if you see any blockers from top of your head
15:21:39 <noonedeadpunk> But since we run haproxy with galera almost at the same time - we can remove that process now
15:22:22 <noonedeadpunk> the only possible one would be case of upgrade from Y to A, but I think it will be still covered
15:23:05 <noonedeadpunk> Btw, I've proposed patches for upgrade script to test Y->AA https://review.opendev.org/c/openstack/openstack-ansible/+/879884
15:23:13 <noonedeadpunk> It obviously fails, but in quite reasonable way
15:23:59 <noonedeadpunk> also right now we basically are testng Y->AA upgrade always, and we have Z->AA broken without that patch
15:30:28 <noonedeadpunk> another thing - we're about to move Xena to the EM
15:30:49 <noonedeadpunk> It should have been already done, but I bought some time to merge things we want for the last proper release
15:30:57 <jrosser> have we done that with earlier branches already?
15:31:03 <noonedeadpunk> Yes
15:31:29 <noonedeadpunk> All before xena is already in Extended Maintenance
15:32:04 <noonedeadpunk> With that, rocky should be EOLed (stable/rocky branch, not rocky linux)
15:33:51 <noonedeadpunk> So basically current blocker is rabbitmq patch https://review.opendev.org/c/openstack/openstack-ansible-rabbitmq_server/+/879856
15:34:07 <noonedeadpunk> After that couple of rechecks can be made. That will also fix upgrade jobs for Y
15:34:35 <jrosser> i just +W the Y version of that - trying to do them in order i guess
15:39:54 <noonedeadpunk> Do we want to discuss anything about haproxy stuff or smth else maybe?
15:40:41 <damiandabrowski> from my side everything is clear, I'll keep adding tls support to service roles
15:41:01 <jrosser> for haproxy i think james added a lot of complexity to the template to handle simultaneous http/https backends
15:41:15 <jrosser> which we said we would revert once a migration is done
15:41:26 <jrosser> if now we are going to not use that, we could remove it
15:42:02 <noonedeadpunk> good point
15:44:17 <damiandabrowski> so: with separated haproxy config we can keep downtime minimal during http->https transition(downtime will start after haproxy config and finish when first host is properly configured)
15:45:17 <damiandabrowski> if it's ok for us(i think it should be ok) then we can revert james' patches mainly because they are quite complex
15:45:43 <damiandabrowski> but if we want to provide literally zero-downtime http->https transition, we will still need them
15:47:27 <noonedeadpunk> Are we leveraging them in any way?
15:48:47 <damiandabrowski> AFAIK this feature is currently broken: https://review.opendev.org/c/openstack/openstack-ansible-haproxy_server/+/864784
15:53:18 <noonedeadpunk> damiandabrowski: well, we can apply filter there, like `"{{ 'ansible_' ~ haproxy_bind_external_lb_vip_interface | replace('-','_') }}"`
15:53:33 <noonedeadpunk> to gather facts only for interfaces of interest
15:53:50 <noonedeadpunk> like we do for masakari for example https://opendev.org/openstack/openstack-ansible/src/tag/wallaby-em/playbooks/os-masakari-install.yml#L34-L35
15:55:31 <damiandabrowski> yeah, it will most likely help
16:04:19 <noonedeadpunk> #endmeeting