16:00:11 <gmann> #startmeeting tc
16:00:11 <opendevmeet> Meeting started Wed Jan 11 16:00:11 2023 UTC and is due to finish in 60 minutes.  The chair is gmann. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:11 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:11 <opendevmeet> The meeting name has been set to 'tc'
16:00:16 <gmann> #topic Roll call
16:00:20 <gmann> o/
16:00:21 <arne_wiebalck> o/
16:00:22 <rosmaita> o/
16:00:22 <dansmith> o/
16:00:26 <JayF> o/
16:00:40 <slaweq> o/
16:01:12 <gmann> today agenda #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Agenda_Suggestions
16:01:36 <spotz> o/
16:01:57 <knikolla[m]> o/
16:02:15 <gmann> let's start
16:02:17 <gmann> #topic Follow up on past action items
16:02:23 <gmann> gmann to ping elod to check the mistral release status
16:02:38 <gmann> that is done, we will discuss it in Mistral topic next
16:02:48 <gmann> #topic Gate health check
16:03:07 <gmann> I think tox4 things are much settled now. though many projects are yet to fix it on master gate
16:03:12 <dansmith> There was some log upload thing yesterday, that I assume is resolved now?
16:03:18 <gmann> but stable branches are pinned with tox<4
16:04:18 <fungi> yes, we had to disable log uploads to ovh's swift regions yesterday due to an outage they were experiencing, but we've reenabled them earlier today
16:04:29 <dansmith> okay
16:04:32 <gmann> ok
16:04:41 <dansmith> also, while not really an *issue*,
16:05:07 <dansmith> it looks like oslo.messaging has changed something about how to get an rpc client, and are emitting a warning when we use the previously-supported way,
16:05:14 <noonedeadpunk> o/
16:05:17 <dansmith> which is generating thousands of warning messages in runs that use it
16:05:24 <gmann> oh
16:05:48 <gmann> no way to disable them in tests or so?
16:05:56 <jungleboyj> :-(
16:06:00 <gmann> like we did for rbac
16:06:23 <dansmith> I haven't looked, but I assume the fix is just to use the new interface, but that might be laborious to fix in all the tests, I dunno
16:06:38 <dansmith> I've been swamped with other things, but it was impeding debug for me this morning :/
16:07:25 <gmann> ok
16:08:24 <gmann> any other things on gate side?
16:08:38 <slaweq> nothing from me
16:08:50 <dansmith> nope
16:09:11 <gmann> ok, let's move next. thanks for reporting
16:09:14 <gmann> #topic Cleanup of PyPI maintainer list for OpenStack Projects
16:09:22 <gmann> we discussed this in last meeting also.
16:10:36 <gmann> to give background, we have some maintainers present/being added newly in PyPi side for OpenStack deliverables and OpenStack team does know even those deliverable were  changed/released out of OpenStack release model
16:10:43 <gmann> this is example of it #link https://github.com/openstack/xstatic-font-awesome/pull/2
16:11:21 <gmann> this repo is under Horizon project. I pinged Horizon team to check the status and whether they know or can collaborate with those external maintainers
16:11:51 <gmann> vishalmanchanda (Horizon PTL) discussed it in today Horizon meeting which was just before the TC meeting
16:12:26 <fungi> for that example, openstackci became a co-maintainer of a project previously maintained by the moinmoin community, and then one of the other co-maintainers uploaded a new version of their own
16:12:42 <gmann> as summary, horizon team will discuss the same with external developers and see how it can be maintained in single place either in openstack or as external to openstack and openstack can be one of the user
16:12:51 <gmann> yeah
16:13:36 <gmann> I will wait for their conversation and see how horizon/external maintainers want to move ahead.
16:14:05 <gmann> so this xstatic is special case here
16:14:25 <fungi> but more generally, we have pypi project entries originally created by accounts of people who haven't been active in the openstack community for nearly a decade, and that presents some risk when they continue to have upload access
16:14:42 <knikolla[m]> ++
16:14:46 <gmann> while checking other repo we do have individual maintainers along with 'openstackci ' for many repo. for exmaple: https://pypi.org/project/murano/
16:15:09 <gmann> yes, most of them are previous PTL or doing the releases in early time
16:15:24 <gmann> it should be easy to cleanup those and only keep 'openstackci ' as maintainers
16:15:29 <JayF> Is there any risk in dropping down to a single maintainer on those pypi repos, mechanically? e.g. If that account somehow got compromised, would we be in any worse shape?
16:15:53 <noonedeadpunk> I assume, that for most deliverables, except some SIGs it does make sense to leave only openstackci as maintainer?
16:15:58 <gmann> that account is owned by opendev side
16:16:04 <gmann> yeah
16:16:17 <noonedeadpunk> I'm not sure there is any reason to have humans for most of things there
16:16:27 <gmann> agree
16:16:56 <fungi> i think the risk in removing all but one maintainer is if we lose control of/access to that account. reducing the number of accounts with access at least reduces the degree of risk from a compromised account
16:17:20 <fungi> it's mainly the "all your eggs in one basket, but protect that basket" approach
16:17:36 <slaweq> I think we agreed that for most of the repos last week, and the open question was for those things like xstatic-font-awesome
16:17:37 <slaweq> or did I missunderstood something?
16:17:47 <gmann> yes and if we keep PTLs there we do have extra work of changing them on regular basis when PTL change
16:18:06 <gmann> slaweq: yes, xstatic is special case we need more discussion
16:18:26 <slaweq> gmann: ok, so I remember correctly :)
16:18:41 <gmann> and yes for other repos, I can send email to ML with PTL tags to check if any projects have any such special case then they can let us know
16:18:55 <noonedeadpunk> Well, adding PTL is kind of tricky, as then we also require PTL to have pypi account
16:19:02 <fungi> still worth discussing is the process for cleaning them up. i can take on making the necessary edits to those project entries on pypi, but would appreciate someone giving me a list of which ones need to be cleaned up (for example i just looked at python-novaclient and it's already fine)
16:19:06 <gmann> otherwise say by m-3 we can ask opendev to do the cleanup and keep only 'openstackci ' as maintainers
16:19:07 <JayF> fungi: ty; that matches my expectation (plus we have friends in pypi who I'm sure would help us recover)
16:19:08 <noonedeadpunk> And have some list in .. .deliverables to autmate that?
16:19:39 <clarkb> fungi: could also have the publication step do the cleanup maybe
16:19:42 <gmann> fungi: yes. let's wait for m-3 to have checks by PTLs and TC can prepare the list to cleanup
16:19:43 <fungi> JayF: yes, the pypi admins can assist in case we happen to lose access for some reason
16:19:44 <clarkb> and let it happen over time
16:19:58 <knikolla[m]> Makes sense. I'm in favor of only keeping openstackci
16:20:02 <JayF> ++
16:20:06 <slaweq> ++
16:20:09 <noonedeadpunk> ++
16:20:15 <gmann> clarkb: but can anyone do it? or may be you or fungi can do as part of openstackci  ?
16:20:19 <fungi> clarkb: that's an interesting approach, we'd need some additional api integration (assuming it's doable via the warehouse api)
16:20:48 <clarkb> gmann: I mean update your publication jobs to check and remove any additional accounts
16:20:48 <fungi> gmann: someone with access to the openstackci account credentials (2fa password and otp) would need to do it
16:21:01 <gmann> yeah
16:21:04 <clarkb> the publication jobs already have access (though maybe not sufficient access with tokens now)
16:21:04 <fungi> unless we can automate it through the api
16:21:23 <fungi> yes, tokens are restricted to uploading, i believe
16:21:38 <gmann> i see. that will be good. I will email today and let's see if we have more cases like xstatic
16:21:39 <knikolla[m]> since this is hopefully a one time process, I don't see a lot of advantage in having the publication job do it.
16:22:13 <clarkb> knikolla[m]: I'm not sure its a one time thing. Depends on how people create their pypi projects
16:22:19 <clarkb> any new project could recreate the problem again
16:22:25 <fungi> well, it's not entirely one-time, we would need to also audit or add automation to block uploads for new projects if they had additional accounrs
16:22:27 <fungi> accounts
16:22:44 <fungi> yeah, that
16:22:48 <gmann> #action gmann to send email to PTLs on openstack-discuss about checking PyPi maintainers list for their projects
16:23:07 <knikolla[m]> ah, makes sense. thanks.
16:23:38 <knikolla[m]> If possible i'd like to keep that auditing process separate from the publish process, just to avoid giving one token too much power that it only needs rarely.
16:24:02 <clarkb> ya thats fine. I'm mostly trying to get it out of fungi and my plate
16:24:11 <clarkb> it should be automatable but that needs investigating
16:24:16 <knikolla[m]> ++
16:24:20 <gmann> sure
16:24:42 <gmann> I will keep this in meeting agenda for audit results and xstatic things
16:24:45 <gmann> anything else on this topic ?
16:25:14 <noonedeadpunk> well, I'm thinking about possibility to shoot ourselvs in leg with automating access revoke
16:26:02 <noonedeadpunk> but yeah, doing that manually sucks as well
16:26:25 <gmann> I am sure it will be lot of deliverables
16:26:46 <knikolla[m]> I've had more oopsies with manual processes than automated processes, to be honest, haha.
16:27:06 <noonedeadpunk> true
16:27:09 <fungi> i automate my manual oopsies
16:27:14 <gmann> that is why doing audit first and then once we are more clear on keeping/discussing with external maintainers like xstatic then doing cleanup is less risky
16:27:44 <JayF> How about we see how prolific the problem is before we choose an intentional course of action?
16:29:00 <gmann> yes we are open to that like xstatic,  for example. any PTL/project can reachout to us that this repo can go to external maintenance than openstack and we can remove that from openstack and give it to external maintainers
16:29:20 <knikolla[m]> JayF, I agree with that. I also think that considering all the "supply chain" stuff happening, one can never get started too early with auditing things like this.
16:29:22 <gmann> that is what I will ask in ML to PTLs/projects to check and decide such case if any
16:30:17 <gmann> true but we will not hurry up the cleanup things until audit are done.
16:30:48 <gmann> if audit are delayed so let's do audit and may be sometime in PTG we can check and decide on cleanup timing.
16:31:25 <gmann> plan: 1. ask PTLs to do audit 2. in PTG check audit status 3. decide on cleanup timing
16:32:01 <gmann> this will give projects time to discuss with external maintainers if they need to do
16:33:10 <gmann> anything else before we move to next topic?
16:33:28 <fungi> also, just a reminder to the auditors, the pypi project names aren't always the same as the repository names
16:33:42 <gmann> ack
16:33:45 <knikolla[m]> I'm sorry, I'm sure the reason why some projects need to have external maintainers in pypi was answered in last weeks meeting, which I had to miss. I'm unsure as to why some projects need external maintainers.
16:34:54 <rosmaita> knikolla[m]: not that they need them, it's usually that they had them before we standardized our processes
16:35:00 <gmann> for many we had previous PTLs who used to do release and initially added project. but somehow for some repo like xstatic new one got added by existing one
16:35:23 <gmann> we never know about those until clarkb reported the xstatic case
16:36:13 <knikolla[m]> Understood. The way gmann was framing the discussion made me think that there was a use case for keeping external maintainers and letting teams decide.
16:36:17 <gmann> issue is when new one gets added without OpenStack know and they do change/release the things in PyPi
16:37:00 <JayF> knikolla[m]: xstatic is the exception that has that potential use case; the other maintainers are from moinmoin, not openstack, so there may actually be a need to hand over maintainership
16:37:22 <clarkb> gmann: note anyone else can subscribe to the repo events in github too
16:37:23 <fungi> or to have a fork under a different name
16:37:26 <gmann> knikolla[m]: we have two options: 1. either project want to keep only openstack in maintainer list and we can cleanup 2. those repo can be removed from openstck and given to external maintainers if both are ok to do so
16:37:27 <JayF> knikolla[m]: but that's being handled separately from the general cleanup of all other openstack pypi deliverables which we're talking about auditing
16:37:42 <clarkb> gmann: there is nothing special in why I saw that. I am subscribed to the repo events and saw the PR conversation
16:37:58 <gmann> clarkb: ack
16:38:17 <knikolla[m]> ++ on a deliverables either only having openstackci, or being handed over to someone else entirely.
16:39:29 <gmann> we do not want to forcefully remvoe the external maintainers if OpenStack project team and they want to maintain it out of OpenStack.
16:40:11 <gmann> any other query on this?
16:40:24 <knikolla[m]> to summarize my point. if handled by openstackci, i'm in favor of starting to build some auditing automation that initially just checks that only openstackci is present in the maintainers list and prints a happy message. we can either have that do some cleanup automatically as well, or not.
16:41:50 <gmann> sure, anyone can automate that but we do need PTLs to check situation/talk to external maintainers if any about xtstaic as part of audit too
16:42:23 <gmann> getting list with automation will help the audit
16:42:54 <knikolla[m]> Yes
16:43:18 <noonedeadpunk> well, for PTL it would be super useful not to check all they can have on PyPi, but eventually be able to look through the list of projects that are having more then openstackci
16:43:33 <gmann> yes
16:44:21 <knikolla[m]> ++
16:44:31 <gmann> I will send email and if we get any automation from anyone helping on listing etc can be added on top of it
16:45:11 <knikolla[m]> Happy to take this on for building some auditing tooling.
16:45:22 <gmann> ++
16:45:52 <gmann> ok, moving next
16:45:55 <gmann> #topic Mistral situation
16:46:01 <noonedeadpunk> then maybe it worth sending audit results in this email? Or well, wait with email until audit will be done
16:46:22 <knikolla[m]> noonedeadpunk: ++
16:46:56 <gmann> knikolla[m]: noonedeadpunk sure, let's wait for next week and then prepare the email but I do not think we should delay if it is taking time to automate it
16:47:47 <gmann> On mistral, Release team proposing it to mark its release deprecated and we were checking Mistral gate and if new core are active or not
16:47:51 <gmann> Gate is fixed (except python-mistralclient)
16:47:57 <gmann> #link https://review.opendev.org/q/topic:gate-fix-mistral-repo
16:48:25 <gmann> and in Mistral channel new/old core are active and fixing/merging the gate fix
16:49:00 <gmann> situation looks better now, I will continue to keep eyes and discussion with release team about it.
16:49:11 <noonedeadpunk> grat news!
16:49:16 <noonedeadpunk> *great
16:49:39 <gmann> elod also checking beta release about it #link https://review.opendev.org/c/openstack/releases/+/869470 https://review.opendev.org/c/openstack/releases/+/869448
16:50:19 <gmann> any query on Mistral situation ?
16:51:01 <avanzagh> nothing to add, you said everythin
16:51:10 <gmann> avanzagh: hi.
16:51:27 <gmann> thanks again for helping to maintain it avanzagh
16:51:56 <gmann> #topic Adjutant situation
16:52:12 <gmann> situation is better for Adjutant. Gate is fixed by PTL
16:52:17 <gmann> Beta release is happening (patch not merged yet but has one +2 from release team)
16:52:27 <gmann> #link https://review.opendev.org/c/openstack/releases/+/869449
16:52:34 <gmann> #link https://review.opendev.org/c/openstack/releases/+/869471
16:52:48 <gmann> things are merging there
16:53:12 <gmann> and with that, Dale (PTL) proposed Adjutant to remove it from Inactive projects list
16:53:16 <knikolla[m]> nice
16:53:24 <gmann> #link https://review.opendev.org/c/openstack/governance/+/869665
16:53:31 <gmann> please review and add your vote/feedback
16:53:31 <noonedeadpunk> does that mean we should move it from inactive once it releases?
16:53:38 <noonedeadpunk> aha
16:53:56 <gmann> noonedeadpunk: I think so. it is ready to release, gate is fixed so it means it is active
16:55:30 <gmann> Its good to see both project getting active maintainers
16:55:43 <gmann> anything else/query on Adjutnat ?"
16:56:27 <gmann> #topic Recurring tasks check
16:56:28 <gmann> Bare 'recheck' state
16:56:37 <gmann> #link https://etherpad.opendev.org/p/recheck-weekly-summary
16:56:45 <gmann> slaweq: please go ahead
16:57:19 <slaweq> I updated data todayu
16:57:19 <slaweq> *today
16:57:21 <slaweq> all looks ok
16:57:47 <gmann> cool, thanks
16:57:48 <slaweq> but I want to have a bit closer look for some projects which have highest numbers of rechecks, not only bare but in general
16:58:02 <gmann> ++, good idea
16:58:06 <slaweq> to see what are the reasons of that many rechecks
16:58:10 <gmann> but this week it might be due to tox4 things
16:58:13 <slaweq> and maybe save some
16:58:16 <jungleboyj> Good news that things are looking ok.
16:58:53 <gmann> ok, moving next
16:58:54 <gmann> #topic Open Reviews
16:59:02 <gmann> #link https://review.opendev.org/q/projects:openstack/governance+is:open
16:59:19 <gmann> four open review, 3 of them are waiting for deps or Mistral check
16:59:28 <gmann> Adjutant status change we already talk so please vote there
16:59:42 <gmann> that is all from today agenda and we are on time
17:00:07 <gmann> next meeting is on 18 Jan on IRC
17:00:14 <gmann> thanks everyone for joining
17:00:18 <gmann> #endmeeting