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