15:02:01 <noonedeadpunk> #startmeeting openstack_ansible_meeting
15:02:01 <opendevmeet> Meeting started Tue May  2 15:02:01 2023 UTC and is due to finish in 60 minutes.  The chair is noonedeadpunk. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:01 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:02:01 <opendevmeet> The meeting name has been set to 'openstack_ansible_meeting'
15:02:05 <noonedeadpunk> #topic rollcall
15:02:07 <noonedeadpunk> o/
15:02:09 <damiandabrowski> hi!
15:03:07 <NeilHanlon> o/
15:03:11 <NeilHanlon> hiya folks
15:03:35 <jrosser> o/ hello
15:04:29 <noonedeadpunk> #topic office hours
15:04:50 <noonedeadpunk> 1st thing is that I will be limited available during the next week
15:05:02 <noonedeadpunk> Close to not available
15:05:16 <noonedeadpunk> I think same goes for damiandabrowski
15:05:26 <damiandabrowski> yup
15:05:49 <noonedeadpunk> So do we wanna have meeting next week or should we cancel it?
15:06:12 <noonedeadpunk> if we wanna keep it - volunteer for meeting chair is needed :)
15:07:11 <jrosser> well maybe we skip it but there is really very much stuff to merge
15:07:31 <noonedeadpunk> and very little time left, yes...
15:07:42 <noonedeadpunk> Timing is awful I know
15:08:26 <noonedeadpunk> Regarding merge - we have 2 broken roles now. It's magnum and zun.
15:08:49 <noonedeadpunk> I haven't looked and zun, but regarding magnum, it's module that is misbehaving
15:09:22 <NeilHanlon> I am around next week and happy to chair, if only to check in on stuff while you are out
15:09:54 <NeilHanlon> could just be me talking to myself, which isn't abnormal
15:10:00 <noonedeadpunk> ok, that would be great then! I will try to join at least from phone
15:11:39 <noonedeadpunk> we have this wiki page regarding meetings that might be helpful (unlikely though) https://wiki.openstack.org/wiki/Meetings/openstack-ansible
15:12:02 <NeilHanlon> hehe, thank you
15:12:23 <NeilHanlon> do i need perms for meetbot?
15:13:00 <noonedeadpunk> nope
15:13:06 <noonedeadpunk> (I guess not)
15:13:19 <noonedeadpunk> the person who starts the meeting become chair :)
15:13:54 <NeilHanlon> ah, fair enough
15:13:56 <noonedeadpunk> so regarding magnum - coe template module in collection is not idempotent anymore which causes the failure
15:14:28 <noonedeadpunk> I will try to fix the module, but likely we need some nasty workaround to get listing of templates and see if we need or not to add ours
15:15:53 <noonedeadpunk> regarding zun - I didn't have chance to check on that yet
15:17:44 <noonedeadpunk> NeilHanlon: btw, I assume you're not aware, but we have a review dashboard, link to it is in IRC description - http://bit.ly/osa-review-board-v4_1
15:18:03 <NeilHanlon> ty!
15:18:04 <noonedeadpunk> So for reviews it might be way easier to check it what needs attention
15:18:36 <NeilHanlon> i really need to manage my bookmarks soon heh
15:19:16 <noonedeadpunk> Talking about that - we need to decide on what jobs we wanna run for ensuring TLS is working.
15:19:28 <noonedeadpunk> I think we should run both ubuntu jammy and rocky 9
15:19:50 <noonedeadpunk> though I'm not sure if this should be lxc/metal or both
15:19:59 <noonedeadpunk> I think metal should be enough to be frank
15:20:29 <noonedeadpunk> Can't think of what can go off in lxc comparing to metal...
15:20:58 <noonedeadpunk> it's wrt https://review.opendev.org/c/openstack/openstack-ansible/+/881968/
15:21:55 <damiandabrowski> I'm okay with it
15:22:04 <jrosser> the only thing different on an lxc job will be having lots of differing hostnames in the certs
15:22:32 <jrosser> though we can probably cover that by making sure we add a tls job to the infra jobs
15:22:33 <mgariepy> and a bunch more ips.
15:22:39 <jrosser> as one of those deploys 3x keystones
15:23:51 <NeilHanlon> good concerns. i could see some unexpected fun with too many alt names
15:24:11 <damiandabrowski> so... focal metal, rocky9 metal and infra?
15:24:19 <jrosser> `openstack-ansible-upgrade-infra_lxc_tls-ubuntu-jammy` or similar
15:24:25 <jrosser> oh, not upgrade :/
15:24:45 <NeilHanlon> damiandabrowski: good with me
15:25:29 <noonedeadpunk> ++ sounds really good
15:25:45 <damiandabrowski> ack, thanks
15:26:22 <noonedeadpunk> another thing, with hardcoding built_wheels: true logic, we've started building them in CI which takes way more time...
15:26:34 <noonedeadpunk> though it's smth that real deployments will have for sure...
15:28:18 <noonedeadpunk> and talking about python_venv_build role there was a bug reported, that architecture is not really respected in current logic and patch was proposed to cover the issue https://review.opendev.org/c/openstack/ansible-role-python_venv_build/+/881848
15:29:33 <noonedeadpunk> While I agree about distro name, I'd say that architecture may still worth being as nested dict
15:29:52 <noonedeadpunk> I can't really recall why I've used __setitem__ to be frank...
15:30:23 <jrosser> let me see if stuart can comment
15:31:18 <jrosser> iirc dealing with the multi-level nested dict is really hard in this code
15:32:45 <jrosser> hi stuart
15:33:01 <stuartgr_> hi
15:33:02 <noonedeadpunk> I kinda just don't have anything aarch64 nearby to test
15:33:08 <jrosser> from just before `noonedeadpunk> While I agree about distro name, I'd say that architecture may still worth being as nested dict `
15:34:04 <noonedeadpunk> But it looked like if/else and update (snippet I've commented) should have worked...
15:34:33 <jrosser> well, it would turn to 3 level hierarchy if we also add distro
15:34:56 <noonedeadpunk> nah, distro can be merged with version I believe....
15:35:18 <stuartgr_> what's the advantage of a nested dict?
15:37:16 <noonedeadpunk> maybe you're right and there's none...
15:38:06 <noonedeadpunk> especially given that in next task we do exactly what you've proposed
15:38:19 <noonedeadpunk> `{%   set distro_arch = [distro, arch] | join('_') %}`
15:39:27 <jrosser> we do this in a bunch of places.... to make the wheel dir name too
15:39:30 <noonedeadpunk> yeah, ok, indeed it doesn't look like matter
15:39:47 <jrosser> so perhaps there could be one var we define as the OS identifer and use it everywhere
15:41:23 <stuartgr_> os_identifier: [distro_name, distro_ver, arch] | join('_')
15:42:38 <noonedeadpunk> I wonder if adding distro_name can affect upgrades
15:43:03 <noonedeadpunk> likely not.... until we backport this
15:43:12 <noonedeadpunk> and it's worth backporting to be frank
15:43:54 <jrosser> apart from this multiarch compute seems to be working on Zed
15:44:03 <jrosser> stuartgr_ is working on that right now in our lab
15:44:16 <noonedeadpunk> sounds really sweet
15:44:54 <jrosser> we added one extra infra node with just utility and repo containers on aarch64
15:45:59 <stuartgr_> Nearly working.. I've just discovered dir /usr/lib/ipxe is missing from the new aarch64 nodes so the VMs aren't booting
15:46:12 <jrosser> so yes, whatever we do should be small/light enough to backport
15:46:31 <opendevreview> Damian Dąbrowski proposed openstack/openstack-ansible master: Add 'tls' scenario  https://review.opendev.org/c/openstack/openstack-ansible/+/881968
15:49:04 <noonedeadpunk> ok, awesome
15:49:17 <noonedeadpunk> but yes, we have really plenty things to review...
15:50:38 <NeilHanlon> I will try to make some time this week to review some things.. this is a quite busy month for us too as we will have rocky 9.2 and 8.8 landing sometime
15:51:04 <noonedeadpunk> 1 huge patch that I've pushed recently is this: https://review.opendev.org/c/openstack/openstack-ansible/+/881824
15:51:32 <noonedeadpunk> NeilHanlon: it would be really awesome if by the release time we could use ovs 3.1 on rocky...
15:51:48 * NeilHanlon moves that into his 'to-do' column
15:51:57 <noonedeadpunk> and rollback workaround that's currently in place
15:52:02 <NeilHanlon> i think that's reasonable to do
15:52:14 <NeilHanlon> i can prioritize that over reviews just to make sure
15:52:22 <noonedeadpunk> sure!
15:52:36 <noonedeadpunk> that's fair)
15:54:00 <opendevreview> Damian Dąbrowski proposed openstack/openstack-ansible master: Add 'tls' scenario  https://review.opendev.org/c/openstack/openstack-ansible/+/881968
15:54:23 <noonedeadpunk> I don't know how to make 881824 really simpler, except make # of services patch and doing the same on per-service basis
15:56:15 <NeilHanlon> i have a feeling it would be harder to track N small changes vs 1 "large" change that's just repetitive
15:58:18 <jrosser> also if we merge it soon before any of the tls patches go in then it gets double-tested
16:00:44 <opendevreview> Damian Dąbrowski proposed openstack/openstack-ansible master: Add 'tls' scenario  https://review.opendev.org/c/openstack/openstack-ansible/+/881968
16:00:45 <noonedeadpunk> oh, yes, true
16:04:15 <noonedeadpunk> #endmeeting