15:03:14 <mnaser> #startmeeting tc
15:03:15 <openstack> Meeting started Thu Jan  7 15:03:14 2021 UTC and is due to finish in 60 minutes.  The chair is mnaser. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:03:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:03:19 <openstack> The meeting name has been set to 'tc'
15:03:29 <mnaser> #topic rollcall
15:03:30 <diablo_rojo> o/
15:03:31 <gmann> o/
15:03:35 <mnaser> o/
15:03:37 <jungleboyj> o/
15:03:37 <belmoreira> o/
15:03:38 <mnaser> happy new year everyone :D
15:03:53 <gmann> happy new year :)
15:03:53 <jungleboyj> Happy New Year!
15:03:54 <belmoreira> happy new year!!!
15:04:19 <mnaser> hope y'all had a good one comfy from home :)
15:04:51 <mnaser> i count 5 people right
15:05:50 * evrardjp lurks and therefore doesn't count
15:06:01 <mnaser> aww
15:06:08 <mnaser> okay well i guess no one corrected my math, so we're good :p
15:06:11 <dansmith> gah, sorry
15:06:22 <mnaser> o/
15:06:25 <mnaser> #topic Follow up on past action items
15:06:30 <dansmith> oh, mnaser was late too, I feel better
15:06:38 <evrardjp> :)
15:06:42 <mnaser> #link http://eavesdrop.openstack.org/meetings/tc/2020/tc.2020-12-17-15.00.html
15:06:59 <mnaser> mnaser send out email about skipping both upcoming meetings <= done, we all decided xmas and nye wasnt the best time to meet :-)
15:07:15 <mnaser> mnaser write a proposed goal for X about stabilization/cooldown <= that didn't start yet, but there's a topic discussing that later today, so i'll keep that for now
15:07:24 <mnaser> diablo_rojo complete retirement of karbor
15:08:17 <mnaser> i think we had a few patches pending mermge or something along those lines? :>
15:08:25 <ricolin> o/
15:08:30 <ricolin> sorry I'm late
15:08:37 <mnaser> o/ ricolin
15:09:15 <mnaser> i guess there is still a few patches left - https://review.opendev.org/q/topic:retire-karbor+is:open
15:09:39 <mnaser> ill keep it as an action item for next week
15:09:45 <mnaser> #action diablo_rojo complete retirement of karbor
15:10:02 <diablo_rojo_phon> +2
15:10:17 <diablo_rojo_phon> Tons of progress, but not done yet
15:10:22 <mnaser> next up was diablo_rojo reach out to SIGs/ML and start auditing states of SIGs -- i think we have that on the agenda, so put it aside for now
15:10:40 <mnaser> mnaser drop X cycle goal selection start from agenda <= done
15:10:47 <mnaser> gmann continue to audit tags + outreach to community to apply for them
15:11:20 <gmann> not much update on this but we have this in agenda where we can talk on this
15:11:26 <mnaser> yep, sounds good
15:11:41 <mnaser> mnaser drop X cycle release name vote recording AND mnaser remove centos 8 topic from upcoming agenda <= both done
15:11:47 <mnaser> cool so
15:11:52 <mnaser> #topic Write a proposed goal for X about stabilization/cooldown (mnaser)
15:12:14 <mnaser> i think i should find the mailing list post but what we had discussed was the idea of having a goal of 'stabilization'
15:12:19 <mnaser> we've had community goals over and over again
15:12:33 <jungleboyj> ++
15:12:40 <mnaser> so the idea was 'its a rough year, we've been doing this for a while, the goal is do whatever you want to do to improve the software (and share if you want), or do nothing, and that's ok"
15:12:53 <gmann> +1
15:12:59 <mnaser> i didn't get thaaat much response to the ML post at the time if i ir emember
15:13:14 <mnaser> #link http://lists.openstack.org/pipermail/openstack-discuss/2020-December/019379.html
15:13:20 <jungleboyj> mnaser:  I don't think there were any objections.  :-)
15:13:41 <gmann> yeah
15:13:44 <gmann> we want to document that or just 'no goal' and ML is ok?
15:13:47 <dansmith> so,
15:13:56 <dansmith> this is just no goals this time, right?
15:14:04 <gmann> yeah for X cycle
15:14:08 <mnaser> yeah, i think we'll have a no goal goal :-p
15:14:14 <jungleboyj> Right.
15:14:16 <dansmith> you're not proposing "add fewer features" or "a goal of stabilizing over any other activity"
15:14:28 <mnaser> correct, that's a good point
15:14:37 <mnaser> i think stabilization of our sanity more than it is of the code
15:14:43 <dansmith> okay, I think it's important to point that out and not say "everybody stop with the features this cycle:
15:14:46 <jungleboyj> We should make sure to call that out.
15:14:57 <dansmith> because we've discussed that before, but we can't align everyone's schedules so it's not popular
15:15:04 <mnaser> i agree
15:15:10 <belmoreira> +1
15:15:11 <gmann> agree
15:15:17 <ricolin> +1
15:16:03 <mnaser> #action mnaser submit a patch to officially list no community goals for X cycle
15:16:10 <mnaser> i think the language is key, thanks for pointing that out dansmith
15:16:21 <jungleboyj> ++
15:16:38 <mnaser> i guess we can do all the voting and vetting in gerrit, unless there's something we can quickly discuss
15:16:38 <gmann> +1, having doc describing this will be helpful for future ref also
15:17:55 <mnaser> ok cool
15:18:05 <mnaser> #topic Audit SIG list and chairs (diablo_rojo)
15:18:53 <mnaser> ping diablo_rojo_phon :)
15:19:10 <diablo_rojo_phon> Yes sorry my laptop is doing a firmware update out of nowhere.
15:19:46 <diablo_rojo_phon> So, I haven't made much progress on this, other than deciding to do the coordination via discuss list rather than reaching out to the listed chairs directly.
15:20:05 <mnaser> no worries -- plus that item has been there over the holidays so not exactly the best timing
15:20:22 <mnaser> we can keep it as an action item to keep following up in our weekly meetings'
15:20:34 <diablo_rojo_phon> I figure it would be better for getting new volunteers for the roles anyway.
15:20:40 <diablo_rojo_phon> Yeah.. holidays.
15:20:47 <mnaser> yeah that's a good idea too, it might have volunteers indeed
15:20:52 <mnaser> cool
15:21:04 <diablo_rojo_phon> And if not, it might be time to retire the Sig.
15:21:08 <mnaser> ++
15:21:10 <mnaser> #action diablo_rojo reach out to SIGs/ML and start auditing states of SIGs
15:21:21 <mnaser> we're gonna have you for a hat trick :)
15:21:24 <mnaser> #topic Annual report suggestions (diablo_rojo)
15:21:30 <jungleboyj> ++
15:22:17 <diablo_rojo_phon> The draft is due next week and mnaser and I put together an outline before the holidays and wanted to make sure there wasn't anything we were missing.
15:22:35 <diablo_rojo_phon> Uhh, mnaser do you have a link to the outline etherpad?
15:22:47 <mnaser> yep: https://etherpad.opendev.org/p/2020-openstack-annual-report
15:22:51 <mnaser> #link https://etherpad.opendev.org/p/2020-openstack-annual-report
15:23:08 <diablo_rojo_phon> There's obviously a ton of stuff we could cover, but we don't want to write a novel.
15:23:50 <diablo_rojo_phon> So we tried to just focus on the biggest most.. impacting things and stuff that were bigger changes to stuff we've historically done.
15:24:22 <mnaser> yep, so tc-members: appreciate adding anything we may have missed
15:24:31 <diablo_rojo_phon> Please add anything you think we don't have listed and NEED to cover by the end of the week so that we can get it all written by the deadline.
15:24:50 <jungleboyj> That looks like a good start.
15:24:55 <gmann> sure
15:25:35 <diablo_rojo_phon> That's all for this topic I think mnaser.
15:25:35 <mnaser> cool cool
15:25:40 <mnaser> alrighty
15:25:42 <mnaser> #topic Add Resolution of TC stance on the OpenStackClient (diablo_rojo)
15:25:49 <mnaser> #link https://review.opendev.org/c/openstack/governance/+/759904
15:26:28 <mnaser> i agree with dansmith commentary and im wondering what we can do to help land this patch based on those comments
15:26:53 <jungleboyj> mnaser:  ++
15:27:17 <jungleboyj> Just looking at those comments and I am ok with softening the language.
15:27:28 <mnaser> gmann: perhaps we can discuss a bit those comments and maybe dansmith has ideas on what we can make changes to exactly to help diablo_rojo_phon wrap this up
15:27:41 <gmann> yeah, either we need to make it high level and not mentioning any detailed decision on python client whether to remove those or not OR decide what to do for standalone cases etc
15:27:52 <diablo_rojo_phon> Yes please :)
15:27:59 <diablo_rojo_phon> It was supposed to be high level.
15:28:06 <jungleboyj> Yeah, would like to get that wrapped up.
15:28:20 <diablo_rojo_phon> Then people kept asking for more detail and we slowly descended into adding it..
15:28:49 <dansmith> well, it's mildly controversial for some people, so wanting more detail is understandable, but yeah I think we just got too deep
15:29:00 <diablo_rojo_phon> Agreed.
15:29:01 <jungleboyj> Agreed.
15:29:17 <jungleboyj> We are taking a stance.  Not telling people what to do.
15:29:34 <diablo_rojo_phon> It's not surprising, but the whole point was to write something vague to keep from backwards progress and have a general direction.
15:29:49 <dansmith> yup
15:29:49 <mnaser> i do see the concern with standalone-inspired projects
15:30:10 <gmann> having everything in osc as single interface and leave the removal/no-removal python*client up to projects.
15:30:22 <gmann> if they have bandwidth and want to support standalone case then  fine
15:30:23 <diablo_rojo_phon> Am open to phrasing suggestions to keep it vague. It's become a longer living patch than I had hoped it would be.
15:30:49 <mnaser> oh i have an idea
15:30:50 <belmoreira> even being a stance shouldn't it be mentioned into the anual report? It would give it some weight
15:31:01 <mnaser> why dont we say aim for removing standalone clients
15:31:06 <mnaser> unless they assert that they support standalone with the tc?
15:31:18 <mnaser> so if a project doesnt assert it supports standalone, it shouldn't be messing about its client
15:31:31 <diablo_rojo_phon> belmoreira: since it hasn't landed we didn't include it in the outline.
15:31:47 <mnaser> but if the project asserts supporting standalone, then it should still support osc first- and be allowed to have its own client
15:31:53 <mnaser> is that ok for 'best of both worlds' ?
15:31:55 <jungleboyj> I think that makes sense but could see people grumbling about that.
15:32:01 <dansmith> yeah, too much detail I think
15:32:08 <dansmith> and by detail, I mean "too much to argue about"
15:32:16 <jungleboyj> dansmith:  ++
15:32:17 <mnaser> very valid
15:32:22 <gmann> yeah, we might end up in old situation
15:32:31 <belmoreira> diablo_rojo_phon true, but has been discussed basically through all year
15:32:37 <diablo_rojo_phon> I think that's a reasonable path, but yeah I fear the arguments.
15:32:51 <gmann> belmoreira: on standalone in annual report? you mean L37 https://etherpad.opendev.org/p/2020-openstack-annual-report
15:33:14 <mnaser> gmann: you're currently -1 -- what can we do to turn that around (and i see dansmith hasn't voted yet, so maybe would like to hear your thoughts)
15:33:41 <dansmith> I had previously, I just got tired of re-adding my vote
15:33:49 <diablo_rojo_phon> belmoreira: I wanted to add it, but I also wanted this patch merged in November lol. We opted not to add it since it's still just a discussion with nothing concrete.
15:34:03 <diablo_rojo_phon> dansmith: you just want it landed too? ;)
15:34:18 <gmann> I agree with what dansmith mentioned. we can leave the removal of python*client and say its up to projects if they want to maintain it or not but but youn have support all your cli in osc along with doc
15:34:32 <belmoreira> diablo_rojo_phon fair enough
15:34:41 <gmann> current version says 'remove the python*client'
15:35:02 <mnaser> so gmann you're suggesting that 'you can keep python*client as long as you have feature parity in osc' ?
15:35:08 <diablo_rojo_phon> belmoreira: it's definitely important to call out and we will make sure it's in the next one once we can point at this resolution (god willing it's landed by then)
15:35:41 <gmann> yeah we just talk about osc in this and leave any discussion on python*client as that is not yet concluded/or having arguments
15:35:47 <mnaser> remember this whole thing stemmed from projects removing testing using osc into their client
15:36:00 <mnaser> and this was to have something to go back to and say
15:36:03 <mnaser> "please stop going backwards"
15:36:17 <gmann> and all doc pointing to osc CLI.
15:36:29 <gmann> which was origin of this discussion i think :)
15:36:35 <dansmith> yeah
15:36:41 <jungleboyj> I think the parity point is key.
15:36:44 <dansmith> I think I covered that in my most recent comment
15:36:50 <gmann> yeah.
15:36:51 <mnaser> so should we drop the remove python*client stuff and add 'should use osc for ci and docs' ?
15:37:00 <gmann> +1.
15:37:17 <jungleboyj> I think that might help reduce argument.
15:38:11 <mnaser> tc-members: ^ thoughts on that so diablo_rojo_phon can make the change?
15:38:38 <mnaser> (of course we'll vote on it but having an early ok to proceed would help the back and forth)
15:38:42 <jungleboyj> I am in support in the interest of moving forward.
15:38:46 <dansmith> yup
15:38:58 <belmoreira> +1
15:39:19 <gmann> sounds good
15:39:19 <mnaser> cool -- diablo_rojo_phon i think we have a way forward with some sort of mostly-agreement here
15:39:21 <ricolin> +1 on drop the `remove` stuff as it make it easy to moving forward as first step
15:39:28 <diablo_rojo_phon> Okay cool.
15:39:38 <diablo_rojo_phon> I will try to get that update up today.
15:39:54 <mnaser> thank you for your patience <3
15:40:07 <mnaser> and next-up
15:40:11 <mnaser> #topic Audit and clean-up tags (gmann)
15:40:22 <mnaser> eh for continuty
15:40:23 <mnaser> #undo
15:40:23 <openstack> Removing item from minutes: #topic Audit and clean-up tags (gmann)
15:40:33 <mnaser> #action diablo_rojo_phon update resolution for tc stance on osc
15:40:37 <mnaser> #topic Audit and clean-up tags (gmann)
15:40:56 <gmann> I was targeting API interop tag and sent ML in dec #link http://lists.openstack.org/pipermail/openstack-discuss/2020-December/019505.html
15:41:03 <gmann> but could not get any response on that.
15:41:20 <mnaser> gmann: maybe a 'bump' on that thread could be good considering holidays and all?
15:41:23 <gmann> may be due to holiday time, i will bump this thread again with PTL tag
15:41:26 <gmann> yeah
15:41:30 <gmann> I will do today
15:41:53 <jungleboyj> ++
15:41:56 <mnaser> #action gmann continue to audit tags + outreach to community to apply for them
15:42:17 <mnaser> anything else for the topic gmann ?
15:42:48 <gmann> nothing else from me.
15:43:10 <mnaser> and a not-so-great topic :(
15:43:15 <mnaser> #topic Farewell Andreas (diablo_rojo)
15:44:34 <mnaser> so: Andreas mentioned they will no longer be able to continue helping with project-config reviews
15:44:55 <mnaser> as far as i know, they were mainly doing it on their own as a contribution and not sponsored at all by their employee to do it for the most part
15:45:44 <mnaser> for context, andreas has had 15333 reviews into project-config!
15:45:53 <jungleboyj> Wow.
15:46:20 <mnaser> 269 in victoria, double the next person after them, so they really were doing a lot of work for helping keeping project-config flowing
15:46:21 <gmann> I can help on project-config zuul jobs/acl things area.
15:46:48 <mnaser> for the most part, the reviews are somewhat trivial but mostly procedural in understanding how a change can affect something else
15:47:24 <mnaser> to be honest, i am on project-config-core but i am not actively checking reviews on a daily basis, so i can certainly try and step up a bit from my side, but i think we'll need something more sustainable
15:48:28 <mnaser> https://review.opendev.org/q/project:openstack/project-config
15:48:57 <mnaser> so some grafana dashboard jobs, some projects.yaml changes, usually addition/retire of projects
15:49:33 <mnaser> the only concern right now is that  openstack/project-config is project-config for * -- so there's some airship/starlingx changes in there too
15:49:42 <fungi> we're happy to add more project-config-core reviewers if folks think they have time to look through changes there
15:50:02 <mnaser> dunno if clarkb or fungi are around to talk about if the idea of splitting that out at some near future (understandibly, it's.. not trivial)
15:50:17 <fungi> even if you're only reviewing openstack config changes that's still the bulk of them so a huge help
15:50:53 <mnaser> fungi: i don't seem to remember off the top of my head right now, is project-config a config-project ?
15:50:56 <gmann> yeah we can do based on incoming requests.
15:51:02 <fungi> and yeah, the eventual plan is for each namespace to have an opendev config repo which contains things like their pipeline configs, trusted central job definitions, acls, et cetera
15:51:29 <fungi> mnaser: it is a trusted "config" project for zuul, yes
15:51:31 <mnaser> if so, the one thing to be somewhat concerned about is the fact that it is essential 'root' zuul access to a degree
15:52:31 <mnaser> so those reviewers would need to exercise care when it comes to things that can include secrets/trusted jobs/etc
15:52:42 <fungi> also because it's trusted content, there's no pre-merge exercising of the zuul configuration in it
15:53:03 <fungi> only takes effect once approved and merged
15:53:39 <mnaser> so zuul job output is not a reflection of the actual change
15:54:17 <gmann> yeah, after merging only. depends-on is no effect for those changes to check the changes in advance
15:54:19 <fungi> well, we do have some linting and other pre-merge tests of non-zuul content in there
15:54:32 <gmann> from service side
15:55:10 <mnaser> hear me out on this: what if we dropped -1/+1 right to * on project-config and adding project-config-shadow, for those people who would like to get involved, and then a full core can merge with one 'shadow' core +1 as a rule for us
15:55:10 <fungi> things like checking acl normalization/syntax, ordering of entries in very long files, checking irc channel permissions before adding bots, et cetera
15:55:23 <fungi> that stuff is still tested
15:55:37 <mnaser> which will help speed up merging stuff (needing 1 person) and also mentoring those looking to become core, and making the actual +1 more meaningful
15:55:59 <mnaser> (generally, i am super happy and welcoming of adding people to core, but i think we just have to be mindful of the trusted context of those repos)
15:56:14 <fungi> that's probably a discussion to be had with more of the opendev administrators, but maybe bring it up on service-discuss
15:56:38 <fungi> i'm also happy to see us just trust people to not approve changes if they're not sure
15:57:05 <mnaser> that's also a very good easy alternative :)
15:57:49 <mnaser> maybe we should discuss this again next week
15:57:52 <gmann> yeah that is fair point, usual practice in many projects
15:57:58 <mnaser> seems like it's quieted down
15:59:11 <mnaser> ok well, i think we can continue this next week
15:59:18 <mnaser> #topic open discussion
15:59:23 <mnaser> and open quick topics?
15:59:37 <fungi> didn't want to interrupt mid-topic earlier, but standalone clients *could* also be rebuilt on top of openstacksdk (it's lightweight even though osc is not particularly, at least not today)
15:59:53 <mnaser> fungi: i think that's what ironic has done afaik, right?
16:00:02 <dansmith> that is for sure the right approach,
16:00:03 <fungi> not sure, but awesome if true
16:00:15 <mnaser> dont quote me on it but i think they have done something like that
16:00:24 <dansmith> but there's a lot of work to make that a thing, when the standalones currently work
16:00:36 <fungi> yep, totally
16:00:47 <fungi> it was more a theoretical
16:00:51 <mnaser> https://github.com/openstack/python-ironicclient/blob/master/setup.cfg#L26-L28
16:00:58 <dansmith> so from the perspective of someone not wanting to do this, it's like "move your code here, then re-write your existing code to use that new stuff"
16:00:59 <fungi> but cool to hear that maybe at least one project has already done that
16:01:24 <mnaser> https://github.com/openstack/python-ironicclient/blob/master/ironicclient/shell.py#L116-L129
16:01:30 <mnaser> if you're curious fungi ^ :)
16:06:16 <jungleboyj> Do we need to End Meeting?
16:06:19 <jungleboyj> :-)
16:06:23 <mnaser> #endmeeting