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