15:00:16 <noonedeadpunk> #startmeeting openstack_ansible_meeting
15:00:16 <opendevmeet> Meeting started Tue Jan 11 15:00:16 2022 UTC and is due to finish in 60 minutes.  The chair is noonedeadpunk. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:16 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:16 <opendevmeet> The meeting name has been set to 'openstack_ansible_meeting'
15:00:18 <noonedeadpunk> o/
15:00:27 <noonedeadpunk> #topic rollcall
15:02:24 <jamesdenton> o/
15:02:51 <jrosser_> o/ hello
15:03:47 <jrosser_> we should be unblocked on master with the linters trouble now i think
15:04:01 <jamesdenton> did the second one merge?
15:04:04 <damiandabrowski[m]> hey!
15:04:06 <jamesdenton> or does it matter?
15:04:23 <noonedeadpunk> #topic office hours
15:04:48 <noonedeadpunk> So this is first meeting 2022 and we have plenty stuff to discuss I bet :)
15:05:36 <noonedeadpunk> I guess first thing is probably Rocky Linux support raised by NeilHanlon last week
15:05:55 <jrosser_> there is a patch now i think
15:06:13 <noonedeadpunk> https://review.opendev.org/c/openstack/openstack-ansible/+/823573
15:06:30 <NeilHanlon> i'm still poking at the DIB build root, too. double booked this morning but i'll try and respond here, too
15:06:46 <jrosser_> NeilHanlon: i guess there is kind of intersection also with this https://review.opendev.org/c/openstack/ansible-role-python_venv_build/+/824189
15:06:48 <noonedeadpunk> I will try to look into this patch and why zuul is unhappy
15:06:49 <jrosser_> oh
15:06:56 <jrosser_> wrong link
15:07:12 <jrosser_> this https://review.opendev.org/c/openstack/openstack-ansible/+/820854
15:07:58 <noonedeadpunk> actually I looked through ^ and didn't find anything that would hurt Rocky much.
15:08:03 <jrosser_> noonedeadpunk: i think there is no rocky image in CI yet
15:08:08 <NeilHanlon> i believe zuul is unhappy b/c of the missing jobs, yea
15:08:11 <jrosser_> which is why the many zuul errors
15:08:56 <noonedeadpunk> btw, NeilHanlon, maybe you know out of top of your brain - does ansible detect that it's Rocky for operating system? And family is still redhat?
15:09:18 <NeilHanlon> versions >2.10 i think should. and yea, family rh
15:09:23 <noonedeadpunk> because we're carrying some nasty stuff for centos 8 (non-stream) which is eoled by now
15:09:39 <NeilHanlon> we *try* to be as close to RHEL as we can
15:09:44 <jrosser_> detecting stream vs. non-stream for 8 is nasty
15:09:49 <NeilHanlon> i bet :(
15:10:05 <NeilHanlon> do you know if there's any reliance on the centos advanced virtualiation sigs? or other SIGs
15:10:33 <noonedeadpunk> another more general question - is there any chances that Rocky will ship python38 selinux bindings? As CentOS does not which is a bit frustrating
15:10:48 <noonedeadpunk> We rely on RDO
15:10:54 <jrosser_> sort of https://github.com/openstack/openstack-ansible-openstack_hosts/blob/master/vars/redhat-8.yml#L91-L106
15:10:54 <noonedeadpunk> for some packages
15:11:06 <noonedeadpunk> ah, yes...
15:11:35 <jrosser_> but "it depends" - there needs to be somewhere that the relevant versions of libvirt and whatever come from
15:12:00 <jrosser_> and if they are there in the distro with no extra repo, then thats fine
15:12:44 <jrosser_> so the long answer is we take RDO / distro / advanced virt / ... as necessary, and it can be a per distro choice
15:13:05 <NeilHanlon> adv virt might be problematic.. i may need to pick that up from CentOS and start building it
15:13:29 <noonedeadpunk> I think nova requirement has libvirt >= 6.0.0 now
15:13:49 <jrosser_> we should have logs of this
15:14:14 <andrewbonney> https://docs.openstack.org/nova/latest/reference/libvirt-distro-support-matrix.html
15:14:35 <noonedeadpunk> jrosser_: btw why do we have advanced-virtualization in openstack_hosts.... Isn't it smth that should be only for nova-computes?
15:14:44 <jrosser_> very good question
15:15:06 <jrosser_> NeilHanlon: in the CI logs you can see what got installed https://zuul.opendev.org/t/openstack/build/4bbcf2f1b948415bba2c20acd6a29c5d/log/logs/redhat-rpm-list-installed-host-20-31-15.txt
15:16:25 <jrosser_> it may be that repo is not required at all
15:17:04 <NeilHanlon> i'll give it a check/test. that repo is going away a/o jan 31st when CentOS rips the 8 content off the mirror
15:17:13 <NeilHanlon> https://lists.centos.org/pipermail/centos-devel/2021-December/098779.html
15:18:12 <noonedeadpunk[h]> I believe I got disconnected :(
15:19:50 <noonedeadpunk[h]> Ok, so for Rocky I think we're fine to add it's support considering it shouldn't really take much effort to support it comparing to CentOS and NeilHanlon is around hopefully to help out with some distro-specific questions :)
15:20:31 <noonedeadpunk> Another topic then.
15:20:49 <noonedeadpunk> I was wondering if we should add Backport_candidate label for our projects in gerrit?
15:20:56 <opendevreview> Jonathan Rosser proposed openstack/openstack-ansible-openstack_hosts master: Remove use of advanced-virtualisation repo for centos  https://review.opendev.org/c/openstack/openstack-ansible-openstack_hosts/+/824202
15:21:05 <jrosser_> that would be a good idea
15:21:16 <jrosser_> it is really easy to forget which things need to be backported
15:22:14 <noonedeadpunk> this would add nasty column, but I belkieve benefit is worth it.
15:22:32 <noonedeadpunk> Will figure out how to make this if no objections
15:22:45 <noonedeadpunk> as we really loose what needs to be backported
15:23:02 <jrosser_> we need an update to the dashboard too
15:23:13 <jrosser_> there is a bunch of other collection stuff getting in there
15:23:34 <noonedeadpunk> ah, I see now
15:24:01 <jrosser_> i did read the zuul docs and was not sure what 'parent project' meant - if that was a useful construct to define "only openstack-ansible repos" to make the dashboard expressions much simpler
15:24:35 <jrosser_> zuul/gerrit
15:25:16 <noonedeadpunk> um, I'm not sure that our projects are parented in gerrit
15:25:30 <jrosser_> no they are not
15:27:10 <noonedeadpunk> and I haven't saw how to do that in project-config tbh
15:27:57 <noonedeadpunk> Well, it would require update as we would need to see backport label as separate table anyway, so will imporve regexp as well
15:28:28 <noonedeadpunk> dashboards in gerrit is nasty beast :(
15:29:12 <noonedeadpunk> ok, one more thing from me. We want to re-use journald-remote internally. But currently it's a playbook that hard to be re-used
15:29:29 <noonedeadpunk> Wdyt about making it an independent role?
15:30:10 <noonedeadpunk> Or maybe we should put it just to ops?
15:30:32 <noonedeadpunk> or as role to plugins repo (to be installable with collection)
15:30:42 <jrosser_> i was just going to say that last one
15:30:58 <jrosser_> neat thing with that is we can use it as a kind of staging area for things like this
15:31:18 <jrosser_> and if it works out then it's little effort
15:32:32 <damiandabrowski[m]> but the one disadvantage i see, is that deprecated rsyslog would have a separate role and remote_journald won't
15:32:52 <damiandabrowski[m]> i'm not sure how important it is for You though
15:32:57 <noonedeadpunk> we should finally drop rsyslog roles :p
15:33:03 <jrosser_> ^ this
15:33:23 <noonedeadpunk> They're still used for ceph I guess though?
15:33:44 <noonedeadpunk> worth having another look on that
15:34:11 <jrosser_> becasue ceph writes it's own logs?
15:34:29 <noonedeadpunk> My concern was that outside of osa bringing in plugins collection is... a bit unclean, but we likely can survive that
15:34:57 <noonedeadpunk> Well last time I checked (which was several years ago) it wasn't able to fully leverage journald
15:35:35 <noonedeadpunk> It's anyway better then current playbook, and as you said - small effort to move to independent role if needed
15:35:59 <noonedeadpunk> I'm not sure how we will test role though, but we don't do it now as well, so...
15:36:31 <noonedeadpunk> I'm fine with adding it to plugins
15:37:08 <damiandabrowski[m]> maybe let's wait with the decision till February, when I'll put some effort to improve remote_journald playbook?
15:37:10 <jrosser_> thats an easy first step agreed
15:37:23 <damiandabrowski[m]> after it's done, we can decide where we want to put it
15:37:30 <jrosser_> if it's going to become a role, then things change a bit
15:37:31 <noonedeadpunk> damiandabrowski[m]: Erik already doing some work on it jsut in case
15:37:45 <jrosser_> we have really nice patterns on python_venv_build / pki for this kind of utility role
15:37:46 <damiandabrowski[m]> ouh, didn't know about it, thanks
15:39:11 <opendevreview> Merged openstack/openstack-ansible master: Add openstack-ansible-plugins as a collection  https://review.opendev.org/c/openstack/openstack-ansible/+/820998
15:40:12 <jrosser_> another topic - what do we do with the etcd role?
15:40:29 <jrosser_> that is blocking centos-8 cleanup atm
15:41:25 <noonedeadpunk> to have this logged - I'm about to move openstack-ansible-plugins to release independent, which means it won't branch, but we will be creating tags for it. but eventually, we can leave things as is and just switch branches for ansible-collection-requirements...
15:42:30 <noonedeadpunk> I'm about to either fork it or move to opendev
15:42:32 <noonedeadpunk> not sure
15:42:33 <jamesdenton> i believe the etcd role is also being leveraged by OVN
15:49:28 <jrosser_> does anyone see why the linters fix fails on victoria?
15:50:42 <jrosser_> oh, we want <11.0.0
15:51:26 <jrosser_> but we have ended up with rich==11.0.0
15:53:03 <noonedeadpunk> oh, weird
15:54:07 <noonedeadpunk> ah, we use functional test there, damn
15:54:28 <jrosser_> yeah, it's tox installing things and not what the patch changes
15:55:22 <noonedeadpunk> but I'm not sure how that worked as we have ansible-lint in https://opendev.org/openstack/openstack-ansible/src/branch/stable/victoria/test-requirements.txt#L14
15:57:10 <jrosser_> comes from here eventually? https://opendev.org/openstack/openstack-ansible/src/branch/master/tox.ini#L140
15:57:39 <noonedeadpunk> and for U that passes because there's no such requirement I guess
15:57:44 <jrosser_> which starts out at https://opendev.org/openstack/openstack-ansible/src/branch/master/tox.ini#L12-L14
15:58:58 <noonedeadpunk> yeah, I guess you're right. But we kind of need to fix that for functional repo as well I guess?
15:59:45 <jrosser_> can we add it go global pins and then it does both together?
15:59:49 <jrosser_> *to
15:59:58 <noonedeadpunk> yep, we can
16:00:43 <noonedeadpunk> it's probably not best place but considering it's only for V....
16:00:53 <noonedeadpunk> but it will work, yes
16:01:19 <noonedeadpunk> #endmeeting