15:03:02 <noonedeadpunk> #startmeeting openstack_ansible_meeting
15:03:02 <opendevmeet> Meeting started Tue Mar 21 15:03:02 2023 UTC and is due to finish in 60 minutes.  The chair is noonedeadpunk. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:03:02 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:03:02 <opendevmeet> The meeting name has been set to 'openstack_ansible_meeting'
15:03:06 <noonedeadpunk> #topic rollcall
15:03:08 <noonedeadpunk> o/
15:03:18 <NeilHanlon> o/
15:03:30 <admin1> o/
15:05:13 <jrosser> o/ hello
15:05:36 <noonedeadpunk> #topic office hours
15:06:12 <noonedeadpunk> I messed up this week and haven't done what I've promised I will do - talking about sending ML regarding PTG and working on haproxy
15:06:27 <noonedeadpunk> And releases :(
15:06:56 <noonedeadpunk> Will cover all my debt till EOD
15:07:52 <noonedeadpunk> Regarding PTG. Last week during TC meeting it was proposed for projects to have operators hours as previous year
15:08:11 <noonedeadpunk> To be frank for me that decision has come too late thus I'm not sure if we should have one or not
15:09:32 <noonedeadpunk> wdyt?
15:09:51 <jrosser> are they well attended?
15:10:09 <noonedeadpunk> well, were mixed feedback from last one
15:10:13 <noonedeadpunk> *was
15:13:14 <jrosser> well - i don't know
15:13:46 <noonedeadpunk> iirc there were couple of unique nicnames in zoom last year for us
15:14:15 <jrosser> well we should do it
15:15:04 <noonedeadpunk> In my report I've sent I've mentioned that around 50% were new ppl on operator hours comparing to PTG
15:15:30 <noonedeadpunk> But given we were 12 ppl, so around 50% could mean 4-5 new folks
15:15:57 <noonedeadpunk> ok. then let's do it :) what time we want to schedule that?
15:16:06 <noonedeadpunk> I assume wednesday?
15:16:32 <jrosser> thats ok for me
15:17:15 <NeilHanlon> I'll try to get a few folks to join that might be interested from Rocky
15:17:32 <noonedeadpunk> like... 17 utc? least occupied slot in terms of intersection
15:17:41 <jrosser> this is next week right?
15:18:04 <noonedeadpunk> Yup
15:18:08 <NeilHanlon> good w/ me
15:18:18 <noonedeadpunk> Awesome NeilHanlon, that would be great
15:18:39 * noonedeadpunk still regrets we didn't catched up on FOSDEM for some beer
15:18:51 <NeilHanlon> me too :( that weekend was so crazy
15:19:38 <noonedeadpunk> Ok, then I'll book an operator hours slot and will include that in email
15:23:18 <noonedeadpunk> Where are we with haproxy topic?
15:23:40 <noonedeadpunk> Since Damian is not around for next couple of weeks (hopefully), I'm going to pick up his part
15:24:52 <jrosser> pretty stalled i think
15:25:07 <jrosser> looking at the topmost-ish patch there is a bit of a mess in the stack https://review.opendev.org/c/openstack/openstack-ansible/+/871189
15:29:06 <jrosser> this is just needing a extra section in the releasenote https://review.opendev.org/c/openstack/openstack-ansible-haproxy_server/+/871188
15:29:36 <noonedeadpunk> aha, but at least we've merged stepca
15:29:51 <noonedeadpunk> and have votes for map files
15:30:43 * NeilHanlon has minor edits for his writings because of StepCA... but that's not a "problem"
15:30:47 <jrosser> well we can maybe try to move things on a bit there after the meeting?
15:30:57 <noonedeadpunk> Well, thinking about extra section, I think maybe it's not needed after all...
15:32:10 <noonedeadpunk> because we're keeping old behaviour for now...
15:32:18 <noonedeadpunk> so deprecation might be enough...
15:32:43 <jrosser> i wonder also if we should consider the scope for this cycle
15:33:01 <noonedeadpunk> yeah, we totally should
15:33:03 <jrosser> like if we don't want a huge rush we could push TLS backends to next cycle
15:33:23 <noonedeadpunk> Except of this haproxy thing I really want to fix systemd_service bug, as it's nasty...
15:33:36 <jrosser> feels like we could land the current haproxy changes and also address the large amount of unmerged stuff
15:34:21 <noonedeadpunk> Well, we're going to have a deployment where internal TLS is going to be an acceptance criteria...
15:34:49 <noonedeadpunk> I'm not sure how good reason is that to land TLS though...
15:35:13 <jrosser> i wonder how close we are with a big set of overrides to enable
15:35:28 <noonedeadpunk> Likely we can use local forks with backports for that...
15:35:28 <jrosser> certainly for haproxy, not the roles though i guess
15:37:03 <jrosser> also nasty is the adding a compute node bug
15:37:24 <noonedeadpunk> I haven't hit that on Xena though
15:37:36 <jrosser> stuarts workaround was to run the playbook with no --limit until it gathered facts from all the compute nodes, CTRL-C at that point and re-run with the limit
15:38:27 <jrosser> and you're sure you don't have facts for the * other compute nodes?
15:38:29 <noonedeadpunk> Well. I've added https://opendev.org/openstack/openstack-ansible/src/branch/master/playbooks/common-tasks/gather-hardware-facts.yml as a standalone playbook to the local collection...
15:38:53 <noonedeadpunk> I _think_ I don't but I will double-check that tomorrow
15:39:29 <jrosser> i think there was someone else also comment on the bug about having the same thing
15:39:39 <noonedeadpunk> yup
15:39:44 <noonedeadpunk> also on Zed jsut in case
15:39:52 <jrosser> hmm ok
15:40:27 <noonedeadpunk> but well. I;ve jsut realized we're having `echo` in front of command for all these years...
15:40:35 <noonedeadpunk> in add-compute.sh
15:40:47 <noonedeadpunk> So it didn't look like being used at all
15:41:55 <noonedeadpunk> but yes, it's quite nasty
15:42:14 <noonedeadpunk> And yeah, I'd try to scope bug fixing mostly this release.
15:42:43 <noonedeadpunk> Eventually, we also need to add n-2 upgrades. It's not a hard requirement this time, but highly appreciated practise
15:43:13 * jrosser looks at current upgrade jobs....
15:43:38 <jrosser> why do we bother running the centos ones :)
15:45:25 <noonedeadpunk> well, they're passing, aren;'t they?
15:45:31 <noonedeadpunk> NV but green
15:46:01 <noonedeadpunk> I think we'd need to add some logic to or extra option to run-upgrade.sh
15:46:40 <noonedeadpunk> as it's not flexible at all about source/target releases
15:46:44 <jrosser> actually the failing ones are distro upgrade jobs
15:47:06 <jrosser> and we don't run any regular non upgrade distro jobs alongside those
15:47:10 <noonedeadpunk> well. distro for ubuntu was passing lately...
15:47:14 <noonedeadpunk> as well as for centos
15:47:25 <jrosser> i was looking here https://review.opendev.org/c/openstack/openstack-ansible/+/877813
15:47:41 <NeilHanlon> i've been meaning to look at distro jobs for rocky soon
15:47:44 * NeilHanlon makes a note
15:47:54 <noonedeadpunk> `'ansible_os_family' is undefined`
15:48:08 <noonedeadpunk> Well, it's caused by quite recent change
15:48:13 <jrosser> my fault :)
15:48:36 <noonedeadpunk> I'm trying to keep an eye on distro from time to time
15:49:00 <jrosser> NeilHanlon: it should be a case of adding a correctly formed job name to the stuff in zuul.d and it should run one
15:49:16 <jrosser> so really small effort to see how far it does/doesnt get
15:49:33 <noonedeadpunk> Given how we're critisized for using u-c - having distro as argument why osa is still good is quite handy
15:49:51 <jrosser> hmm yes well i do notice those comments too
15:50:22 <noonedeadpunk> I still see using packages as a nightmare deployment
15:50:25 <jrosser> but thats a univeral problem for all community deployment tools that dont have a huge army of QA people keeping packages updated
15:51:31 <noonedeadpunk> yeah, so then you should rely on your distro and unattended-upgrades...
15:51:45 <noonedeadpunk> (no)
15:52:44 <noonedeadpunk> eventually one more thing that raised couple of times - if we want to make some migration guide from tripleo to have a good picture and hopefully get more users/maintainers for rhel distros
15:53:25 <noonedeadpunk> That could be quite profitable but I struggle having even very humble estimate of time for that...
15:54:26 <opendevreview> Jonathan Rosser proposed openstack/openstack-ansible master: Fix openstack client installs for 'distro' method  https://review.opendev.org/c/openstack/openstack-ansible/+/878114
15:57:18 <NeilHanlon> noonedeadpunk: i'll take a stab at that.. might have a coworker who would be interested
15:57:28 <noonedeadpunk> oh rly?
15:57:46 <NeilHanlon> have a few technical sales people who like writing :P
15:58:28 <NeilHanlon> when do 'experimental' jobs run? i see a rocky distro metal job configured right now
15:58:47 <noonedeadpunk> Because eventually transfer to osa might be more straightforward as we're having distro path, which is same rdo.
15:59:00 <noonedeadpunk> NeilHanlon: you need to comment on some change `check experimental`
15:59:26 <NeilHanlon> ah.. i will move to check then for 'fun' :)
16:00:41 <opendevreview> Jonathan Rosser proposed openstack/openstack-ansible master: Add rockylinux-9 distro metal job to check pipeline  https://review.opendev.org/c/openstack/openstack-ansible/+/878115
16:00:50 <NeilHanlon> darn you beat me to it :P
16:00:54 <jrosser> oh!
16:01:05 <NeilHanlon> no worries.. afk for a bit anyways :)
16:01:19 <noonedeadpunk> yeah, that would work as well :D
16:01:39 <jrosser> i wonder why we have check pipeline on those jobs but not gate
16:01:43 <jrosser> that is odd
16:01:44 <noonedeadpunk> Maybe we should actually replace distro job with rocky - as we've agreed some time ago to make more focus on rocky comparing to c9s
16:01:50 <NeilHanlon> #yolo ... yolo
16:02:06 <noonedeadpunk> but never had time to follow up on that
16:02:24 <jrosser> hopefully that would be pretty easy, and bring some more stability
16:03:15 <opendevreview> Jonathan Rosser proposed openstack/openstack-ansible master: Add rockylinux-9 distro metal job to check pipeline  https://review.opendev.org/c/openstack/openstack-ansible/+/878115
16:03:41 <noonedeadpunk> yeah, or at least ways to fix will be around faster :)
16:03:48 <noonedeadpunk> #endmeeting