16:00:11 #startmeeting tc 16:00:11 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:11 The meeting name has been set to 'tc' 16:00:16 #topic Roll call 16:00:20 o/ 16:00:21 o/ 16:00:22 o/ 16:00:22 o/ 16:00:26 o/ 16:00:40 o/ 16:01:12 today agenda #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Agenda_Suggestions 16:01:36 o/ 16:01:57 o/ 16:02:15 let's start 16:02:17 #topic Follow up on past action items 16:02:23 gmann to ping elod to check the mistral release status 16:02:38 that is done, we will discuss it in Mistral topic next 16:02:48 #topic Gate health check 16:03:07 I think tox4 things are much settled now. though many projects are yet to fix it on master gate 16:03:12 There was some log upload thing yesterday, that I assume is resolved now? 16:03:18 but stable branches are pinned with tox<4 16:04:18 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 okay 16:04:32 ok 16:04:41 also, while not really an *issue*, 16:05:07 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 o/ 16:05:17 which is generating thousands of warning messages in runs that use it 16:05:24 oh 16:05:48 no way to disable them in tests or so? 16:05:56 :-( 16:06:00 like we did for rbac 16:06:23 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 I've been swamped with other things, but it was impeding debug for me this morning :/ 16:07:25 ok 16:08:24 any other things on gate side? 16:08:38 nothing from me 16:08:50 nope 16:09:11 ok, let's move next. thanks for reporting 16:09:14 #topic Cleanup of PyPI maintainer list for OpenStack Projects 16:09:22 we discussed this in last meeting also. 16:10:36 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 this is example of it #link https://github.com/openstack/xstatic-font-awesome/pull/2 16:11:21 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 vishalmanchanda (Horizon PTL) discussed it in today Horizon meeting which was just before the TC meeting 16:12:26 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 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 yeah 16:13:36 I will wait for their conversation and see how horizon/external maintainers want to move ahead. 16:14:05 so this xstatic is special case here 16:14:25 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 ++ 16:14:46 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 yes, most of them are previous PTL or doing the releases in early time 16:15:24 it should be easy to cleanup those and only keep 'openstackci ' as maintainers 16:15:29 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 I assume, that for most deliverables, except some SIGs it does make sense to leave only openstackci as maintainer? 16:15:58 that account is owned by opendev side 16:16:04 yeah 16:16:17 I'm not sure there is any reason to have humans for most of things there 16:16:27 agree 16:16:56 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 it's mainly the "all your eggs in one basket, but protect that basket" approach 16:17:36 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 or did I missunderstood something? 16:17:47 yes and if we keep PTLs there we do have extra work of changing them on regular basis when PTL change 16:18:06 slaweq: yes, xstatic is special case we need more discussion 16:18:26 gmann: ok, so I remember correctly :) 16:18:41 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 Well, adding PTL is kind of tricky, as then we also require PTL to have pypi account 16:19:02 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 otherwise say by m-3 we can ask opendev to do the cleanup and keep only 'openstackci ' as maintainers 16:19:07 fungi: ty; that matches my expectation (plus we have friends in pypi who I'm sure would help us recover) 16:19:08 And have some list in .. .deliverables to autmate that? 16:19:39 fungi: could also have the publication step do the cleanup maybe 16:19:42 fungi: yes. let's wait for m-3 to have checks by PTLs and TC can prepare the list to cleanup 16:19:43 JayF: yes, the pypi admins can assist in case we happen to lose access for some reason 16:19:44 and let it happen over time 16:19:58 Makes sense. I'm in favor of only keeping openstackci 16:20:02 ++ 16:20:06 ++ 16:20:09 ++ 16:20:15 clarkb: but can anyone do it? or may be you or fungi can do as part of openstackci ? 16:20:19 clarkb: that's an interesting approach, we'd need some additional api integration (assuming it's doable via the warehouse api) 16:20:48 gmann: I mean update your publication jobs to check and remove any additional accounts 16:20:48 gmann: someone with access to the openstackci account credentials (2fa password and otp) would need to do it 16:21:01 yeah 16:21:04 the publication jobs already have access (though maybe not sufficient access with tokens now) 16:21:04 unless we can automate it through the api 16:21:23 yes, tokens are restricted to uploading, i believe 16:21:38 i see. that will be good. I will email today and let's see if we have more cases like xstatic 16:21:39 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 knikolla[m]: I'm not sure its a one time thing. Depends on how people create their pypi projects 16:22:19 any new project could recreate the problem again 16:22:25 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 accounts 16:22:44 yeah, that 16:22:48 #action gmann to send email to PTLs on openstack-discuss about checking PyPi maintainers list for their projects 16:23:07 ah, makes sense. thanks. 16:23:38 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 ya thats fine. I'm mostly trying to get it out of fungi and my plate 16:24:11 it should be automatable but that needs investigating 16:24:16 ++ 16:24:20 sure 16:24:42 I will keep this in meeting agenda for audit results and xstatic things 16:24:45 anything else on this topic ? 16:25:14 well, I'm thinking about possibility to shoot ourselvs in leg with automating access revoke 16:26:02 but yeah, doing that manually sucks as well 16:26:25 I am sure it will be lot of deliverables 16:26:46 I've had more oopsies with manual processes than automated processes, to be honest, haha. 16:27:06 true 16:27:09 i automate my manual oopsies 16:27:14 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 How about we see how prolific the problem is before we choose an intentional course of action? 16:29:00 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 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 that is what I will ask in ML to PTLs/projects to check and decide such case if any 16:30:17 true but we will not hurry up the cleanup things until audit are done. 16:30:48 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 plan: 1. ask PTLs to do audit 2. in PTG check audit status 3. decide on cleanup timing 16:32:01 this will give projects time to discuss with external maintainers if they need to do 16:33:10 anything else before we move to next topic? 16:33:28 also, just a reminder to the auditors, the pypi project names aren't always the same as the repository names 16:33:42 ack 16:33:45 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 knikolla[m]: not that they need them, it's usually that they had them before we standardized our processes 16:35:00 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 we never know about those until clarkb reported the xstatic case 16:36:13 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 issue is when new one gets added without OpenStack know and they do change/release the things in PyPi 16:37:00 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 gmann: note anyone else can subscribe to the repo events in github too 16:37:23 or to have a fork under a different name 16:37:26 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 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 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 clarkb: ack 16:38:17 ++ on a deliverables either only having openstackci, or being handed over to someone else entirely. 16:39:29 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 any other query on this? 16:40:24 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 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 getting list with automation will help the audit 16:42:54 Yes 16:43:18 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 yes 16:44:21 ++ 16:44:31 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 Happy to take this on for building some auditing tooling. 16:45:22 ++ 16:45:52 ok, moving next 16:45:55 #topic Mistral situation 16:46:01 then maybe it worth sending audit results in this email? Or well, wait with email until audit will be done 16:46:22 noonedeadpunk: ++ 16:46:56 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 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 Gate is fixed (except python-mistralclient) 16:47:57 #link https://review.opendev.org/q/topic:gate-fix-mistral-repo 16:48:25 and in Mistral channel new/old core are active and fixing/merging the gate fix 16:49:00 situation looks better now, I will continue to keep eyes and discussion with release team about it. 16:49:11 grat news! 16:49:16 *great 16:49:39 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 any query on Mistral situation ? 16:51:01 nothing to add, you said everythin 16:51:10 avanzagh: hi. 16:51:27 thanks again for helping to maintain it avanzagh 16:51:56 #topic Adjutant situation 16:52:12 situation is better for Adjutant. Gate is fixed by PTL 16:52:17 Beta release is happening (patch not merged yet but has one +2 from release team) 16:52:27 #link https://review.opendev.org/c/openstack/releases/+/869449 16:52:34 #link https://review.opendev.org/c/openstack/releases/+/869471 16:52:48 things are merging there 16:53:12 and with that, Dale (PTL) proposed Adjutant to remove it from Inactive projects list 16:53:16 nice 16:53:24 #link https://review.opendev.org/c/openstack/governance/+/869665 16:53:31 please review and add your vote/feedback 16:53:31 does that mean we should move it from inactive once it releases? 16:53:38 aha 16:53:56 noonedeadpunk: I think so. it is ready to release, gate is fixed so it means it is active 16:55:30 Its good to see both project getting active maintainers 16:55:43 anything else/query on Adjutnat ?" 16:56:27 #topic Recurring tasks check 16:56:28 Bare 'recheck' state 16:56:37 #link https://etherpad.opendev.org/p/recheck-weekly-summary 16:56:45 slaweq: please go ahead 16:57:19 I updated data todayu 16:57:19 *today 16:57:21 all looks ok 16:57:47 cool, thanks 16:57:48 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 ++, good idea 16:58:06 to see what are the reasons of that many rechecks 16:58:10 but this week it might be due to tox4 things 16:58:13 and maybe save some 16:58:16 Good news that things are looking ok. 16:58:53 ok, moving next 16:58:54 #topic Open Reviews 16:59:02 #link https://review.opendev.org/q/projects:openstack/governance+is:open 16:59:19 four open review, 3 of them are waiting for deps or Mistral check 16:59:28 Adjutant status change we already talk so please vote there 16:59:42 that is all from today agenda and we are on time 17:00:07 next meeting is on 18 Jan on IRC 17:00:14 thanks everyone for joining 17:00:18 #endmeeting