15:00:23 <noonedeadpunk> #startmeeting openstack_ansible_meeting
15:00:23 <opendevmeet> Meeting started Tue Jan 18 15:00:23 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:23 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:23 <opendevmeet> The meeting name has been set to 'openstack_ansible_meeting'
15:00:29 <noonedeadpunk> #topic rollcall
15:00:31 <noonedeadpunk> o/
15:02:03 <mgariepy> hey
15:02:07 <damiandabrowski[m]> hey!
15:02:24 <jrosser> hello
15:02:46 <noonedeadpunk> #topic office hours
15:03:05 <noonedeadpunk> We did pretty good job on moving things to plugs!
15:03:09 <noonedeadpunk> *plugins
15:03:29 <noonedeadpunk> The thing we miss now is proper CI testing of what we have there
15:03:54 <jrosser> there must be something "simple" we can use there in place of the tests repo
15:04:04 <jrosser> does anyone have experience with molecule?
15:04:15 <noonedeadpunk> While leveraging some standart ansible bootstraping
15:04:25 <noonedeadpunk> to ensure versions are same and all stuff is in place
15:04:46 <noonedeadpunk> not really. very basic only
15:05:26 <noonedeadpunk> I actually was thinking about even more simple things:) like a playbook/role inside tests that will do just functional testing
15:05:41 <noonedeadpunk> like we do for config_template.
15:05:48 <noonedeadpunk> But maybe molecule is indeed better
15:08:20 <noonedeadpunk> but I guess we still need the way to start jobs and make it in single place
15:09:01 <jrosser> i'm concerned with things like the PKI role that we have no test coverage and they are critical
15:09:48 <jrosser> well, we test it in an AIO, but thats not checking all the things in ansible-role-pki are not broken
15:10:34 <noonedeadpunk> yes, I agree we need some kind of "functional" testing anyway
15:11:48 <noonedeadpunk> I wonder if we can just limit things to tox considering we still run integrated pre-step (which does all bootstrapping)
15:12:35 <jrosser> yes - i mentioned before making some sort of exit point in the existing stuff
15:13:03 <jrosser> then perhaps call {{ role_name }}/tests/main.yml
15:13:21 <noonedeadpunk> yeah
15:13:24 <noonedeadpunk> I agree here
15:13:36 <noonedeadpunk> Sounds good for me.
15:13:53 <noonedeadpunk> I can't promise I will have time during this week to look into that though
15:13:54 <jrosser> though i remember that including tasks / playbooks based on a var name is kind of hard
15:14:13 <jrosser> ^ playbook
15:14:16 <noonedeadpunk> but we have project name in zuul vars?
15:14:58 <noonedeadpunk> but yeah, we run shell script actually (gate-check-commit)
15:15:05 <noonedeadpunk> But I think it's smth solvable tbh
15:15:09 <jrosser> ok
15:17:41 <noonedeadpunk> A had a quick look at https://review.opendev.org/c/openstack/openstack-ansible-plugins/+/825113 and it looks good.
15:18:19 <jrosser> there are some things i need to add but yes the guts of it is there
15:18:45 <jrosser> and i've had it working here in a POC way, now i need to rework os_nova in my AIO to use it for real
15:19:11 <noonedeadpunk> I guess we need to draw some line to which extent we push things to plugins repo. Do we consider it as sandbox?
15:19:50 <jrosser> i think it is a great place as a sandbox, and somewhere to get POC code like this tested in zuul with zero effort
15:20:04 <jrosser> we can in parallel decide if we need a new repo / top level role
15:20:37 <jrosser> perhaps this role is similar enough to PKI role that it should be external
15:20:57 <jrosser> but for sure the mq/db setup stuff should stay in plugins, so there is a line to draw somewhere
15:21:05 <jrosser> perhaps based on re-usability
15:22:04 <damiandabrowski[m]> it's also not so clear for me, when something should be placed in -ops repo, and when in -plugins
15:23:05 <damiandabrowski[m]> for ex. we're going to put journald-remote in '-plugins' but repos like grafana or elk are placed in '-ops'
15:23:14 <jrosser> for ops repo we don't really provide any warranty that stuff works
15:23:22 <jrosser> it's best effort, or example code
15:23:39 <noonedeadpunk> Actually that's good question I was thinking about.
15:23:58 <noonedeadpunk> Tbh I think that journald code should probably be located also in -ops
15:24:19 <noonedeadpunk> but to make it re-usable we need to do huge work on ops repo to make it collection as well
15:24:29 <noonedeadpunk> which probably would be great thing to do
15:25:18 <jrosser> maybe the ops repo is also kind of an incubator
15:25:30 <jrosser> and there is an argument that ELK and MNAIO are mature enough to factor out
15:27:34 <damiandabrowski[m]> so maybe we should define what warranty we want to provide for sandbox/POC things in plugins repo :D
15:27:43 <damiandabrowski[m]> but I don't have any vision how should it work :/
15:28:09 <jrosser> i think it is down to expectations
15:28:23 <jrosser> we have an ELK stack in our prod environment deployed from the ops repo
15:28:38 <jrosser> but i know we have to maintain/fix that ourselves to keep it being useful
15:29:19 <jrosser> thats different to OSA, where the expectation is that you can raise a LP bug and someone will triage/fix stuff thats broken
15:30:30 <noonedeadpunk> Tbh I see ops as incubator more but we need to tranform it to smth re-usable (collection) to make it usable that way
15:33:16 <jrosser> we should talk about the qdrouterd role
15:33:36 <jrosser> it still blocks the stable branch centos-8 removal and i have no time to look at it currently
15:34:33 <jrosser> a possibility is that we remove the depends-on and when the centos-8 removal happens, infra would probably force-push the patches to address zuul job errors
15:36:25 <noonedeadpunk> hm, yes
15:40:09 <noonedeadpunk> IIRC there was an issue with functional jobs in general...
15:40:20 <jrosser> right
15:40:34 <noonedeadpunk> I will try to look into there this week. If not, let's just disable test for it...
15:40:55 <jrosser> something was odd with the glance-nfs ones and i decided to backport the integrated test rather than sink more time into the functional ones
15:41:39 <jrosser> maybe a good time to make a reminder that contributors are always welcome :)
15:43:05 <noonedeadpunk> oh, btw, about that.
15:43:40 <noonedeadpunk> I pushed a patch to drop sub-osa groups which were made per-roles https://review.opendev.org/c/openstack/project-config/+/824230
15:45:09 <noonedeadpunk> They actually had some ppl I never knew, but also permissions for johnsom for os_octavia and some more repo....
15:46:17 <johnsom> That was courtesy access as I was the Octavia PTL.
15:47:17 <johnsom> I am not really active there anymore, so it's not a problem if you remove it.
15:47:30 <noonedeadpunk> it's anyway great that you're always around and ready to help)
15:47:48 <johnsom> I try. grin
15:48:08 <noonedeadpunk> so I'm more about that we add ppl we know/trust as osa cores if they want to rather then maintain per-role ACLs
15:49:16 <johnsom> Definitely would be easier to audit/keep on top of
15:50:07 <noonedeadpunk> jrosser: wdyt?
15:51:06 <jrosser> i'm happy to add people
15:51:26 <jrosser> and also reducing the complexity in the ACL is good otherwise it will rot
15:51:27 <noonedeadpunk> ofc worth writing emails to the effected ppl....
15:51:32 <jrosser> like it had done
15:51:39 <noonedeadpunk> it did...
15:52:09 <noonedeadpunk> ok, awesome then
15:52:24 <noonedeadpunk> I kind of doubt it will add active contributors though :(
15:56:17 <noonedeadpunk> Also Release-Candidate label is placed on top of that change as I was sooo lazy to add it to every role ACL which I wanted to drop...
15:57:04 <noonedeadpunk> *Backport-Candidate
15:57:11 <jrosser> speaking of release, we are probably due a point release
15:57:29 <noonedeadpunk> yes, I was just checking what we have on stable branches to run bumps
15:57:31 <jrosser> i think that the nova ssh config is the only major problem we had in the X release
16:00:55 <noonedeadpunk> would be nice to have though https://review.opendev.org/q/topic:%22cherrypick-combine-filter-recursion-b4njjwtez2%22+(status:open)
16:01:31 <noonedeadpunk> but yeah rest seems to be centos-8 drop so can be ignored
16:02:23 <noonedeadpunk> I think the only question for X - should we do bugfix (24.0.1) or minor (24.1.0) release? I'd say this bugfix and next can be minor...
16:03:05 <damiandabrowski[m]> bugfix is fine for me but I don't have a strong opinion here
16:04:29 <noonedeadpunk> the question here is that we ususally say that first point release is when it's known to be safe for upgrades
16:05:14 <noonedeadpunk> with current stable/xena I'd say it is. But still I'd way for another 2 weeks before doing point release
16:05:23 <noonedeadpunk> s/point/minor/
16:05:39 <noonedeadpunk> oh, and we're out of time :)
16:05:41 <noonedeadpunk> #endmeeting