15:00:17 <gmann> #startmeeting tc
15:00:18 <openstack> Meeting started Thu May 27 15:00:17 2021 UTC and is due to finish in 60 minutes.  The chair is gmann. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:19 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:22 <openstack> The meeting name has been set to 'tc'
15:00:28 <gmann> #topic Roll call
15:00:31 <gmann> o/
15:00:34 <ricolin> o/
15:00:36 <dansmith> o/
15:01:07 <yoctozepto> o/
15:02:26 <gmann> let's start
15:02:29 <gmann> #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Agenda_Suggestions
15:02:37 <gmann> Today agenda ^^
15:02:55 <gmann> #topic Follow up on past action items
15:03:08 <gmann> one AI
15:03:28 <gmann> gmann to push the resolution for ATC/AC terms
15:03:46 <gmann> I did not do that, will continue on this
15:04:02 <gmann> #action gmann to push the resolution for ATC/AC terms
15:04:23 <gmann> #topic Gate health check (dansmith/yoctozepto)
15:04:45 <diablo_rojo> o/
15:04:48 <dansmith> tbh, I haven't pushed many patches in the last week (which is -> :( )
15:04:57 <dansmith> so I don't have any gut feelings on things
15:05:20 <dansmith> I know nova has a live migration spurious fail, but I don't think that is affecting anyone else
15:05:44 <dansmith> obviously there have been other "health" items to be dealing with :)
15:06:01 <gmann> ok
15:06:27 <spotz> o/
15:06:57 <gmann> I have not seen frequent failure this week.
15:07:36 <dansmith> great
15:07:39 <gmann> anyone has anything to share on gate health ?
15:08:11 <yoctozepto> nothing from me
15:08:25 <gmann> Update about ELK help,
15:08:57 <gmann> Board will be discussing it in their meeting and we are also adding it as upstream investment opportunity
15:09:25 <dansmith> cool
15:09:54 <yoctozepto> ++
15:09:56 <gmann> about openstack-health dashboard which need subunit2sql. if we get ELK help then mtreinish can help on maintaining subunit2sql
15:10:18 <gmann> so if we are able to save ELK then we can save subunit2sql and o-h dashboard too
15:10:56 <spotz> We definitely need to let folks know of that aterfall
15:11:01 <spotz> waterfall even
15:11:10 <gmann> yeah
15:11:38 <gmann> let's move next
15:11:39 <gmann> #topic Planning for TC + PTL interaction (gmann)
15:11:50 <gmann> #link https://etherpad.opendev.org/p/tc-ptl-interaction
15:12:11 <gmann> not much feedback on etherpad about choosing option
15:12:25 <gmann> if all agree, I would like to discuss here about it.
15:12:46 <gmann> I feel we can go with option2 which is 'meet once in a release cycle'
15:13:11 * mnaser late walk-in
15:13:20 <gmann> we can decide pre-PTG time or very first day of PTG
15:13:28 <gmann> what other think about it?
15:13:40 <dansmith> sounds good to me.. once per cycle, somewhere near PTG
15:13:41 <yoctozepto> pre/post PTG definetely and once per cycle is enough
15:13:58 <yoctozepto> so 3 folks for that option so far
15:14:07 <yoctozepto> and other tc-members? ;-)
15:14:23 <spotz> I'm leaning pre-PTG so if therre's anything we can help with during the PTG we know\
15:14:40 <yoctozepto> yeah, pre-PTG might be better than post
15:14:50 <diablo_rojo> if its just one week out before the ptg I can do that
15:14:58 <diablo_rojo> more than that and I am busier with preparing
15:15:45 <gmann> exact time we need to decide based on PTL availability. I would not say we fix the time instead we can check the availability at time to ~PTG
15:16:12 <yoctozepto> makes sense, we could also have adjusted sessions
15:16:27 <gmann> yeah
15:16:30 <gmann> I see no objection on option2 and no one in favor of option1 so let's final option2
15:16:38 <yoctozepto> ++
15:16:50 <spotz> ++
15:16:58 <ricolin> +1
15:17:05 <gmann> I will work on the draft proposal but after fixing the channel things
15:17:16 <diablo_rojo> sounds good
15:17:26 <gmann> #topic Xena cycle tracker status check
15:17:37 <gmann> this week is our Xena cycle tracker status check
15:17:50 <gmann> #link https://etherpad.opendev.org/p/tc-xena-tracker
15:18:08 <gmann> if anyone start working on any item please add your progress/link etc in etherpad
15:18:44 <gmann> one update from me is I am keeping  contributor guide patches as -W as we have to update the IRC things there https://review.opendev.org/q/topic:%2522project-ptl-and-contrib-docs%2522+status:open
15:19:20 <gmann> any other update form anyone on their item
15:19:58 <gmann> I see no goal idea in Y cycle etehrpad #link https://etherpad.opendev.org/p/y-series-goals
15:20:13 <gmann> one is one me for RBAC which i did not get time in this week too :(
15:20:33 <yoctozepto> don't feel bad, I'm time-starved as well
15:20:38 <gmann> ricolin: diablo_rojo_phon any other update or lead in this?
15:20:46 <dansmith> finishing RBAC is going to be a multi-cycle process for glance, fwiw
15:20:49 <diablo_rojo> Sadly none from me
15:20:58 <spotz> This is the most I've been online this week
15:20:58 <dansmith> we have a bunch of refactoring we have to do before we can proceed past where we are
15:21:03 <gmann> dansmith: with Xena + Y or more further ?
15:21:06 <diablo_rojo> I havent had much time in the last couple weeks.
15:21:29 <dansmith> gmann: potential finish in Y, but the rate things are going with reviews on my PoC, I'm skeptical
15:21:46 <gmann> dansmith: I see.
15:21:49 <dansmith> gmann: point being, I think RBAC is good, but it might need to be one of those recurring ones :)
15:22:09 <ricolin> I do looking around in community goal etherpad to find potential goals, and do found something might be great
15:22:16 <ricolin> #link https://etherpad.opendev.org/p/community-goals
15:22:23 <ricolin> like 11. Test with TLS (formerly SSL) by Default
15:22:27 <ricolin> or 23. Finish moving legacy python-*client CLIs to python-openstackclient
15:22:33 <ricolin> or 27. add container-images
15:22:43 <gmann> dansmith: yeah, shipping consistent RBAC even across all project is always issue from us
15:22:58 <dansmith> ricolin: we do 11 in a lot of places, no?
15:23:21 <yoctozepto> dansmith: and not in a lot of places as well
15:23:27 <ricolin> dansmith, yes, but no fully
15:23:30 <gmann> I think devstack is default to TLS right
15:23:32 <yoctozepto> we checked that recently in qa
15:23:40 <yoctozepto> and the default is being overridden
15:23:42 <yoctozepto> all over the place
15:23:43 <gmann> ah
15:23:49 <gmann> i remember now
15:23:53 <ricolin> exactly
15:23:55 <dansmith> not fully, granted
15:23:57 <yoctozepto> we added an experimental+periodic job to test notls
15:24:04 <yoctozepto> because it's that popular
15:24:12 <yoctozepto> vide https://review.opendev.org/c/openstack/devstack/+/741807
15:24:34 <yoctozepto> https://codesearch.opendev.org/?q=tls-proxy%3A%20false&i=nope&files=&excludeFiles=&repos=
15:24:42 <yoctozepto> this is a good goal
15:24:56 <dansmith> so what
15:25:03 <dansmith> is the goal, remove the ability to turn it off?
15:25:18 <yoctozepto> that's the final outcome
15:25:23 <yoctozepto> and it's sane
15:25:52 <gmann> on OSC, yes we need that but ricolin did you check with Artem,  there is email in openstack-discuss about work plan
15:25:52 <ricolin> it actually broken if consider to run most services with tls
15:26:06 <gmann> #link http://lists.openstack.org/pipermail/openstack-discuss/2021-May/022535.html
15:26:13 <dansmith> ricolin: is that service broken-ness or devstack lib/foo brokenness?
15:26:17 <yoctozepto> yeah, some probably don't configure things around CA right
15:26:32 <yoctozepto> dansmith: I believe mostly devstack lib/foo
15:26:35 <ricolin> heat try to enable it for testing and appears need to fix in some services before heat can support it
15:26:37 <dansmith> right, okay
15:26:52 <ricolin> service broken-ness I think
15:26:58 <dansmith> lib/foo brokenness is unforunate but fixing it is work without a lot of gain to the actual projects
15:27:08 <dansmith> if it's service brokenness then I totally agree
15:27:11 <ricolin> gmann, not yet
15:27:16 <yoctozepto> dansmith: yeah, but we can't say which is which
15:27:17 <dansmith> obviously we may not be able to determine one without the other
15:27:20 <ricolin> but I will
15:27:20 <dansmith> yep
15:27:21 <gmann> until we have job running with TLS on project side
15:28:02 <gmann> may we can just identified first how many fail with devstack remove the ability of  disabling it as WIP patch.
15:28:21 <ricolin> agree
15:28:39 <gmann> and then we can see how much work needed and this needs to be a goal or not
15:28:58 <dansmith> so I think that devstack's notls arrangement is also how we test standalone services right?
15:29:13 <dansmith> I think that there's some linkage there, IIRC
15:29:35 <dansmith> if so, that's going to be a problem for people (like glance) that insist on bucking the wsgi thing :)
15:29:45 <gmann> humm
15:29:59 <yoctozepto> I don't really remember tbh
15:30:12 <dansmith> glance also has resolutely decided to reject OSC entirely, which is relevant for the other suggestion here
15:30:12 <ricolin> I will set up patches  to check if there is value for diving that one
15:30:35 <yoctozepto> ricolin ++
15:30:42 <gmann> ricolin: yeah and on ML to ask project to test
15:30:54 <dansmith> I'm happy for the TC to choose both of these goals and hope we can change some hearts and minds with it, I'm just pointing it out :)
15:31:12 <gmann> #action ricolin to start testing patch for TLS and send on ML.
15:31:42 <gmann> dansmith: yeah OSC work seems disappear after we did resolution :)
15:31:47 <gmann> instead of triggering it more
15:31:52 <dansmith> heh
15:31:56 <diablo_rojo> Not necessarily
15:32:02 <dansmith> we've lost a lot of OSC people since as well
15:32:08 <gmann> yeah
15:32:09 <diablo_rojo> I had 8 students working on it over the last several months
15:32:27 <diablo_rojo> Manila and Cinder have made huge progress.
15:32:29 <gmann> diablo_rojo_phon: great, I remember manila intern.
15:32:37 <diablo_rojo> All the nova microversion work is almost done
15:33:02 <ricolin> on OSC?
15:33:03 <dansmith> orly, news to me, but cool
15:33:08 <diablo_rojo> ricolin, yep
15:33:09 <gmann> I did not know about those. is there any etherpad, ML thread to track/know this.
15:33:31 <fungi> it's easy to assume nothing is happening in a project you don't pay attention to ;)
15:33:32 <gmann> i remember we agreed to make this as PoPup team and track things but it did not happen
15:33:40 <diablo_rojo> I mean, I kept etherpads with the students but thats not really what you're looking for.
15:33:41 <gouthamr> +1 more manila Outreachy intern working on OpenStackSDK for the next three months :)
15:33:55 <gmann> great
15:33:59 <diablo_rojo> gmann, the popup team didnt really actually get created
15:34:04 <gmann> yeah
15:34:09 <ricolin> gmann, do you remember who was the one driving this potential goal?
15:34:13 <ricolin> I mean OSC one
15:34:29 <gmann> if we have that much progress in this cycle the i think it make sense to make this as goal in Y
15:34:36 <diablo_rojo> gouthamr, and I still have the OSU intern helping with nova and placement stuff in the SDK
15:34:48 <dansmith> diablo_rojo: when is it glance's turn?
15:34:48 <diablo_rojo> gmann, I think I might hold off for one more release
15:35:05 <diablo_rojo> dansmith, glance is actually in a pretty good spot already
15:35:06 <gmann> ricolin: i remember belmoreira
15:35:25 <gmann> ricolin: and Artem  proposed it many time in past
15:35:51 <dansmith> diablo_rojo: mordred added some basic import support for something I needed before he left,
15:35:59 <dansmith> but I think there are some pretty big gaps, IIRC
15:36:05 <gmann> diablo_rojo: dansmith I think we can focus glance via intern then it will be big pre-work and go ahead for goal
15:36:40 <ricolin> gmann, that will be great indeed
15:36:42 <diablo_rojo> dansmith, I had talked to artem about things that needed to get done and I think he said there was some OSC work left for glance but the SDK is at parity?
15:36:51 <diablo_rojo> I might be misremembering though
15:37:01 <dansmith> I'm hiiiiighly skeptical :)
15:37:30 <dansmith> also, last I heard from glance people, there was some fundamental brokenness about image membership assignment things
15:37:31 <diablo_rojo> Well come join the next sdk/osc meeting and ask ;)
15:37:35 <dansmith> I'll have to dig that back up
15:37:38 <gmann> ok, let's get someone to propose it as goal and which cycle we can select it based on progress
15:37:56 <diablo_rojo> I would save it for Z
15:37:59 <diablo_rojo> not Y
15:38:14 <diablo_rojo> just so we can use this next release to get more organized and do prep work
15:38:17 <gmann> yeah, but we can propose it in Xena itself and select in Y or Z
15:38:21 <dansmith> diablo_rojo: yeah the version I have on my devstack machine has no import ability, just a --with-import on the image create, which isn't really much
15:38:28 <diablo_rojo> Fair
15:38:59 <diablo_rojo> dansmith, hmmm alright, will have to chat with artem then
15:39:06 <dansmith> oh,
15:39:10 <dansmith> and totally no multistore support
15:39:25 <dansmith> glance is planning to remove non-multistore at some point, which will be a big problem if osc doesn't have that at all
15:39:41 <diablo_rojo> okay
15:40:08 <gmann> dansmith: but is glance ok to move on osc now?  or its just resource issue?
15:40:27 <dansmith> gmann: they have been -2 on it since forever, AFAIK
15:40:42 <dansmith> part of it is because it's not complete and that membership thing is wrong or something,
15:40:49 <dansmith> and they have no interest in working on it
15:41:00 <fungi> the glance team wants a dedicated cli/sdk they control directly
15:41:03 <gmann> yeah, as diablo_rojo mentioned we have 8 inter working on osc we can get some bandwidth from them to work on glance too ?
15:41:04 <dansmith> but, if some intern hours are able to resolve that and TC sets a goal, maybe we can sway some minds
15:41:27 <gmann> yeah,
15:41:33 <diablo_rojo> gmann, had not have. Currently I think between gouthamr and I we have 3
15:41:35 <dansmith> yep, I'd be glad to help direct some of that effort, but I can't promise the team will embrace osc afterwards
15:41:51 <gmann> diablo_rojo: ack,
15:42:17 <ricolin> dansmith, sounds like some update from glance team is required as action
15:42:17 <gmann> let's go with that plan only. keep intern in osc work and also in glance may be future inter and also compose goal in parallel
15:42:33 <gmann> intern
15:42:36 <diablo_rojo> okay
15:42:49 <gmann> ricolin: diablo_rojo thanks for updates and work on collecting Y goal.
15:43:05 <gmann> #topic Migration plan for 'Freenode' to 'OFTC' (gmann)
15:43:21 <gmann> this is just to tell TC who did not join yesterday emergency meeting.
15:43:35 <gmann> please read ML about plan
15:43:40 * jungleboyj sneaks in late.
15:43:49 <gmann> and i added resolution also to record it as official TC motion
15:44:07 <diablo_rojo> I would have joined had I not been asleep when the announcement about the emergency meeting went out lol.
15:44:09 <fungi> i also went back and tried to address remaining/post-meeting questions on the etherpad as well
15:44:20 <gmann> great
15:44:33 <fungi> there was apparently some confusion over which channels existed, but hopefully my answers cleared that up
15:45:12 <gmann> as this resolution we need to merge soon (before migration planned date), is there any way to get formal-vote topic before 7 days timeline ?
15:45:26 <gmann> mnaser: ^^ if you know or we did something in past
15:45:34 <dansmith> gmann: I'm ready to vote when you fix the latest set of comments
15:45:38 <gmann> fungi: +1
15:45:48 <fungi> the tc could also just retroactively merge that resolution
15:45:52 <dansmith> I say this is an emergency resolution :)
15:45:58 <gmann> dansmith: yoctozepto sure, I will fix
15:46:11 <yoctozepto> ok
15:47:14 <gmann> I do not find anything to merge resolution in emergency in charter or house rule.
15:47:15 <fungi> something to add to the charter to do list: define provisions for emergency resolutions
15:47:32 <gmann> yeah, that we need to add seems
15:47:45 <dansmith> it doesn't really matter, does it? I mean if we have to wait a week to merge a thing that is effectively already done, meh?
15:48:01 <jungleboyj> :-)
15:48:05 <fungi> i think it would need to be in the charter since that defines how motions are handled
15:48:22 <fungi> house rules are more about non-motion changes
15:48:46 <fungi> dansmith: yeah, that's what i meant by retroactive
15:48:57 <dansmith> ack
15:49:10 <gmann> dansmith: if TC agree on this I think we can merge after a week or so, but if TC chaneg their mind then it is difficult situation :)
15:49:18 <fungi> officially the charter says a resolution can't merge this quickly, but that doesn't mean that the activity it describes has to wait
15:49:31 <dansmith> fungi: right, that's what I'm thinking
15:49:41 <dansmith> gmann: just amend to say "and no take-backs"
15:49:51 <dansmith> gmann: "finder's keeper's"
15:49:54 <yoctozepto> lol
15:50:08 <gmann> because of L132 in 3link https://etherpad.opendev.org/p/openstack-irc
15:50:08 <fungi> but for future-proofing, ways to identify an "emergency resolution" or "urgent motion" or whatever could be helpful
15:50:56 <dansmith> agree
15:51:35 <gmann> let's wait for defined deadline only which is 7 days from yesterday and then update charter for future situation handling
15:52:02 <gmann> everyone, please review that and I will fix comment together by end of today.
15:52:26 <gmann> #topic Open Reviews
15:52:38 <gmann> #link https://review.opendev.org/q/project:openstack/governance+is:open
15:55:11 <gmann> most of them have min favorable vote I will merge the eligible one. seems script has some issue on counting the number of days
15:55:20 <gmann> anything else for today ?
15:56:25 <gmann> let's close then thanks everyone for joining
15:56:31 <gmann> #endmeeting