15:00:00 <mnaser> #startmeeting tc
15:00:01 <openstack> Meeting started Thu Dec 17 15:00:00 2020 UTC and is due to finish in 60 minutes.  The chair is mnaser. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:02 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:04 <openstack> The meeting name has been set to 'tc'
15:00:09 <jungleboyj> o/
15:00:11 <mnaser> #topic rollcall
15:00:13 <mnaser> o/
15:00:19 <belmoreira> o/
15:00:44 <gmann> o/
15:00:55 <diablo_rojo> o/
15:01:54 <mnaser> #topic skipping next meetings
15:02:12 <mnaser> i forgot to update the wiki on this, but i assume we're all okay with skipping the 2 upcoming meetings?
15:02:23 <belmoreira> +1
15:02:29 <mnaser> i'll gladly run it on the 24th and 31st if anyone really wants to be there ;)
15:03:18 <mnaser> so i guess in that case, we're probably going to skip those and meet again on january 7th
15:03:21 <gmann> I can but as most of us will not be available so I think skip is fine.
15:03:25 <gmann> +1
15:03:44 <mnaser> cool cool cool
15:03:57 <mnaser> #action mnaser send out email about skipping both upcoming meetings
15:04:01 <jungleboyj> +1
15:04:04 <mnaser> #topic Follow up on past action items
15:04:23 <mnaser> #link http://eavesdrop.openstack.org/meetings/tc/2020/tc.2020-12-10-15.01.html
15:04:35 <mnaser> mnaser send email to ML to find volunteers to help drive goal selection
15:05:21 <mnaser> so i sent that email out
15:05:26 <mnaser> abotu the idea of a stabilization cycle
15:05:49 <mnaser> no one seems to be strongly opposing it :)
15:05:55 <jungleboyj> :-)
15:06:13 <mnaser> #action mnaser write a proposed goal for X about stabilization/cooldown
15:06:18 <mnaser> i'll push up something about that
15:06:22 <gmann> +1
15:06:23 <diablo_rojo> Why would people oppose stabilization? :)
15:06:42 <mnaser> diablo_rojo: mOvE fAsT aNd BrEaK tHiNgS
15:06:43 <jungleboyj> I think we all need a bit of stability right now.
15:06:46 <mnaser> :P
15:06:50 <mnaser> next up, we had: gmann complete retirement of searchlight & qinling
15:06:57 <diablo_rojo> jungleboyj, lol +2
15:07:12 <gmann> both are done, repo cleanup, project-config and  governance patches are merged. few usage patches on kolla side etc are left because their CI is broken currently. they can be merged as soon as their CI is green.
15:07:42 <mnaser> ok that's cool, so shall we keep this as an action item to keep following up or just consider it done?
15:07:46 <mnaser> your call gmann :)
15:08:12 <gmann> we can consider as done, I will follow on recheck those once CI is back
15:09:05 <mnaser> cool cool, ty
15:09:15 <mnaser> next up, diablo_rojo complete retirement of karbor
15:09:38 <diablo_rojo> Getting there. I have the bulk of things done - just a couple kolla and kayobe patches left I think.
15:09:45 <diablo_rojo> Things are starting to merge.
15:10:03 <diablo_rojo> Definitely want to keep this action item lol
15:10:14 <mnaser> haha, got it, sounds good
15:10:18 <mnaser> #action diablo_rojo complete retirement of karbor
15:10:18 <diablo_rojo> But waaaaay more progress than our last time touching base
15:10:31 <mnaser> \o/ awesome, ping me if you need any project-config patches to land
15:10:38 <mnaser> and finally, mnaser work to find time for community deployment projects + centos/rdo team
15:11:04 <mnaser> i reached out to apevec and working on setting that up though most likely it'll be happening next year cause its too close to holidays now
15:11:06 <diablo_rojo> mnaser, I think there are a couple.
15:11:16 <mnaser> diablo_rojo: send em my way whenever :)
15:11:22 <diablo_rojo> Sounds good.
15:11:24 <diablo_rojo> will do.
15:11:31 <mnaser> ok cool, so next up
15:11:34 <mnaser> #topic Audit SIG list and chairs (diablo_rojo)
15:11:42 <mnaser> #link https://governance.openstack.org/sigs/
15:12:21 <diablo_rojo> Oh yeah. So, this list is suuuuuper out of date so I was going to go and email the discuss list about each of them encouraging them to update details- specifically chairs.
15:12:42 <diablo_rojo> I know a lot of these people aren't active anymore and so we should get new chairs in place or look at retiring the sig
15:12:49 <diablo_rojo> or hibernating it or whatever
15:13:05 <diablo_rojo> So I guess thats another action item for me
15:13:13 <mnaser> i think that'll be really useful
15:13:17 <jungleboyj> That is a good idea.
15:13:23 <gmann> what all SIG ?
15:13:26 <jungleboyj> This does look really old.
15:13:47 <mnaser> gmann: a lot of sigs seem to not be so active and/or chairs arent around
15:14:02 <gmann> if any SIG are complete their purpose then  we move them to advisory state
15:14:14 <gmann> otherwise close
15:14:19 <diablo_rojo> gmann, most of them aside from like.. a handful- scientific, first cotnact, TaCT, Large Scale are all probably fine.
15:14:33 <diablo_rojo> gmann, yeah I plan to start those conversations
15:15:00 <gmann> +1, we can check and then move their state
15:15:10 <mnaser> #action diablo_rojo reach out to SIGs/ML and start auditing states of SIGs
15:15:22 <gmann> I think even we close them we keep them in doc for refence
15:15:36 <diablo_rojo> gmann, I would agree
15:15:45 <diablo_rojo> in case someone wants to revive it down the road
15:15:55 <gmann> yeah
15:15:58 <jungleboyj> That sounds good.
15:16:22 <mnaser> cools
15:16:23 <gmann> I cannot find such example in site now but I am sure we have in SIG repo code somewhere
15:16:43 <mnaser> i think once we start hitting that problem, we can discuss on the best way of moving it/archiving it
15:16:57 <diablo_rojo> +2
15:17:28 <mnaser> cool, next up
15:17:32 <mnaser> #topic Annual report suggestions (diablo_rojo)
15:17:38 <diablo_rojo> Also me lol
15:17:45 <diablo_rojo> its the diablo_rojo show today
15:18:07 <diablo_rojo> So mnaser and I are working on the annual report for openstack.
15:18:27 <diablo_rojo> If there are any specific ideas you think we should include, please send them our way
15:18:42 <diablo_rojo> once its mostly written we will send around a draft before submitting it
15:19:30 <gmann> diablo_rojo: mnaser this is process on retiring the SIG https://governance.openstack.org/sigs/reference/sig-guideline.html#retiring-a-sig
15:19:40 <gmann> #link https://governance.openstack.org/sigs/reference/sig-guideline.html#retiring-a-sig
15:19:42 <diablo_rojo> gmann, oh cool! thanks :)
15:19:44 <mnaser> oh that's neat to add later
15:20:01 <mnaser> also wrt to the annual report stuff, yeah, appreciate any info to tack onto it
15:21:12 <mnaser> ok cool
15:21:13 <mnaser> thats fiar
15:21:15 <mnaser> well next
15:21:17 <mnaser> #topic X cycle goal selection start
15:21:30 * jungleboyj stabilized
15:21:35 <mnaser> i think that has to go with the action item that i had above
15:21:37 <gmann> yeah this can be removed now
15:21:47 <mnaser> cool, we can keep track of it in the AI
15:22:06 <gmann> +1 that's better
15:22:06 <mnaser> #action mnaser drop X cycle goal selection start from agenda
15:22:14 <mnaser> #topic Audit and clean-up tags (gmann)
15:22:31 <gmann> I started ML on API tag
15:22:35 <gmann> #link http://lists.openstack.org/pipermail/openstack-discuss/2020-December/019505.html
15:22:57 <gmann> let's see how many projects start that but it might be after holiday
15:23:28 <gmann> I will continue on other tag audit in parallel
15:23:41 <mnaser> ok cool, that seems reasonable
15:23:51 <mnaser> should we remove those sub items in there in the meantime too?
15:24:23 <gmann> yes those can be removed and I will update next tag for next meeting
15:24:39 <mnaser> gmann: mind doing that when you update for next tag for next meeting?
15:24:45 <gmann> sure
15:25:00 <mnaser> #action gmann continue to audit tags + outreach to community to apply for them
15:25:32 <mnaser> #topic X cycle release name vote recording (gmann)
15:26:15 <gmann> should we close this as votes are recorded in ML but only 4 out of 6.
15:26:38 <mnaser> yeah, i guess that's ok at this point
15:26:56 <mnaser> #action mnaser drop X cycle release name vote recording
15:27:07 <mnaser> #link http://lists.openstack.org/pipermail/openstack-discuss/2020-December/019337.html
15:27:13 <gmann> I thinks getting votes from all community members is easy process than getting from TC
15:27:24 <jungleboyj> :-(
15:27:32 <mnaser> i agree
15:27:37 <mnaser> *shrug*
15:28:28 <gmann> anyways something we can discuss later in next meeting or so when all members are here
15:28:32 <mnaser> yeah
15:28:43 <mnaser> #topic CentOS 8 releases are discontinued / switch to CentOS 8 Stream (gmann/yoctozepto)
15:28:51 <mnaser> is there anything to discuss on this at this point from a tc level?
15:29:02 <mnaser> we have an action item to get the community to get together and i trust that the QA team is donig the right hing
15:29:21 <jungleboyj> Man, this has caused a lot of frustration in general.
15:29:25 <gmann> I do not think so, in devstack we are trying to get centos stream job working
15:29:57 <gmann> jungleboyj: yeah I agree
15:30:08 <mnaser> yeah i think that's a whole another discussion we can have
15:30:19 <mnaser> i dont particularly agree with the source of the frustration
15:30:29 <mnaser> but that's another discussion to have :P
15:30:34 <mnaser> we can probably drop this from our list?
15:30:48 <jungleboyj> mnaser:  Agree.
15:30:50 <gmann> yeah. +1 on dropping from our list
15:31:11 <mnaser> coools
15:31:34 <mnaser> #action mnaser remove centos 8 topic from upcoming agenda
15:31:37 <mnaser> #topic open reviews
15:31:42 <mnaser> https://review.opendev.org/q/projects:openstack/governance+is:open
15:31:45 <mnaser> #link https://review.opendev.org/q/projects:openstack/governance+is:open
15:33:04 <mnaser> only main thing is
15:33:09 <mnaser> #link https://review.opendev.org/c/openstack/governance/+/759904
15:33:39 <mnaser> what can we do to help merge this?  or maybe get it in a minimal merge state and then allowing us to amend thing to it later?
15:33:53 <gmann> my -1 is mainly on python-*client stands where we create again confusion on what direction we should do
15:34:58 <gmann> for OSC, projects side point sicne starting was what to do with existing python-*client which is still unclear in this resolution
15:35:19 <gmann> that is why i think we should have some technical debt first and get agreement on that.
15:35:56 <mnaser> i think the main point of the change at the time that projects SHOULDNT do things like remove osc usage and replace it by python-*client
15:36:18 <mnaser> and more in general try to aim to make osc to have feature parity if not .. better?
15:37:18 <gmann> yeah that we can make resolution saying these ^^ and leave technical details like 'remove the python-*client'
15:37:43 <gmann> if resolution talk about these two part then I am good
15:38:20 <gmann> * technical details like 'remove the python-*client which lead the discussion on how sdk python binding should be done
15:38:49 <jungleboyj> I am ok with that.
15:38:57 <fungi> this discussion also conflates openstackclient with openstacksdk, fwiw
15:39:14 <gmann> because Tom raised good point on standalone service client
15:40:06 <mnaser> standalone service clients can make sense if they somehow find a way to be 100% feature parity (i think ironic does something like this)
15:40:36 <mnaser> but tbh when you enter the domain of two different implementations, that's just doing our users a disservice
15:41:59 <jungleboyj> Dual maintenance.
15:42:36 <jungleboyj> If there is parity then we don't have to have them removed but it leave room for confusion/mistakes.
15:43:18 <belmoreira> what's the advantage to not remove them?
15:44:00 <belmoreira> for a simple user that would be very confusing
15:44:08 <belmoreira> like today
15:44:08 <fungi> one advantage is stand-alone projects may not want to force users to install a heavyweight client/sdk to interact with just their service
15:44:16 <gmann> standalone is one oint
15:44:18 <gmann> point
15:44:23 <gmann> #link https://review.opendev.org/c/openstack/governance/+/759904/7/resolutions/20201028-openstackclient-tc-policy.rst#11
15:45:05 <belmoreira> fungi gmann true
15:45:24 <fungi> but that's ultimately a tension between the view that openstack should be one big consistent system vs a federation of compatible but separate solutions
15:46:13 <fungi> it's tough to reconcile those with a single approach to interfaces (for example would you use horizon as a webui for standalone swift?)
15:46:30 <gmann> we also provide the standalone tag for services and operator to choose those #link https://governance.openstack.org/tc/reference/tags/assert_supports-standalone.html
15:46:56 <gmann> so that point we should consider on removing the python-*client
15:48:04 <fungi> one (very labor intensive so unlikely) solution could be to reimplement te individual clients on top of openstacksdk
15:51:17 <fungi> at least the command-line part of them (so basically a compatibility shim to the standalone client syntax where possible)
15:52:32 <ricolin> do we have stand along service who already said they prefer not doing anything to force users to install a heavyweight (which I don't think it's heavy:) ) client/sdk?
15:53:34 <gmann> ricolin: that is the point from manila team  #link https://review.opendev.org/c/openstack/governance/+/759904/7/resolutions/20201028-openstackclient-tc-policy.rst#11
15:54:56 <gmann> and other projects like ironic,  have not opinioned on this yet
15:55:31 <fungi> again, the situations with openstackclient and openstacksdk, while related, are a little different at the moment
15:55:54 <ricolin> right, from gouthamr
15:56:58 <fungi> remember that for now openstackclient still relies on (almost?) all of the individual service client libraries along with depending on openstacksdk
15:57:17 <fungi> that's not the end goal, but it's a present reality
15:57:33 <jungleboyj> Reading over those comments it seems that the main concern is with us making a stance on removal.  I am ok with softening out stance in the interest of making progress.
15:57:59 <jungleboyj> Removal of the python-*client
15:58:24 <fungi> so openstacksdk is remarkably lightweight, openstackclient is a massive grab-bag of dependencies
15:58:59 <ricolin> jungleboyj, +1 as the first step in road to push/encourage projects start this task
15:59:45 <jungleboyj> :-)
15:59:48 <gmann> yeah, if we talk on moving to osc and not updating doc etc not to use osc, basically two point mnaser mentioned above then it is ok.
16:00:11 <jungleboyj> ++
16:00:26 <ricolin> ++
16:01:21 <gmann> and leave the implementation detail on python binding and removal or python-*client for sdk and projects team side
16:02:17 <gmann> at least before TC decide any resolution on that part.
16:02:27 <mnaser> i think we'll keep the discussion going....
16:02:32 <mnaser> #endmeeting