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