| gmann | diablo_rojo: yeah, all set. | 01:35 |
|---|---|---|
| *** ricolin has joined #openstack-tc | 02:08 | |
| *** ricolin has quit IRC | 02:20 | |
| *** ricolin has joined #openstack-tc | 02:30 | |
| *** ricolin has quit IRC | 02:51 | |
| *** ricolin has joined #openstack-tc | 03:05 | |
| *** markvoelker has joined #openstack-tc | 03:06 | |
| *** markvoelker has quit IRC | 03:11 | |
| *** ricolin has quit IRC | 03:45 | |
| *** ricolin has joined #openstack-tc | 03:45 | |
| *** diablo_rojo has quit IRC | 03:58 | |
| *** dmellado has quit IRC | 03:59 | |
| *** evrardjp has quit IRC | 04:33 | |
| *** evrardjp has joined #openstack-tc | 04:33 | |
| *** ricolin has quit IRC | 04:33 | |
| *** markvoelker has joined #openstack-tc | 04:44 | |
| *** markvoelker has quit IRC | 04:49 | |
| *** ricolin has joined #openstack-tc | 04:56 | |
| *** markvoelker has joined #openstack-tc | 05:04 | |
| *** markvoelker has quit IRC | 05:09 | |
| *** ricolin has quit IRC | 05:14 | |
| *** ricolin has joined #openstack-tc | 05:14 | |
| *** ricolin has quit IRC | 05:26 | |
| *** ricolin has joined #openstack-tc | 05:28 | |
| *** dklyle has quit IRC | 06:26 | |
| *** rpittau|afk is now known as rpittau | 06:34 | |
| *** ralonsoh has joined #openstack-tc | 06:37 | |
| *** belmoreira has joined #openstack-tc | 06:49 | |
| *** markvoelker has joined #openstack-tc | 07:05 | |
| *** markvoelker has quit IRC | 07:11 | |
| *** tosky has joined #openstack-tc | 07:35 | |
| *** markvoelker has joined #openstack-tc | 07:49 | |
| *** markvoelker has quit IRC | 07:54 | |
| *** ricolin has quit IRC | 08:39 | |
| *** e0ne has joined #openstack-tc | 08:42 | |
| *** e0ne_ has joined #openstack-tc | 08:43 | |
| *** e0ne has quit IRC | 08:44 | |
| ttx | regarding ansible surprising their community with announcement of red hat product strategy -- this is how Canonical used to do ubuntu back when I was there. And this is why "open design" is baked into the 4 opens. | 08:45 |
| ttx | Ubuntu was pretty successful at open source and open development, so it was a good base. But it was failing with design (still an ivory tower within canonical), and real governance (the top-level governance body was sabdfl + people he suggests for potential election) | 08:46 |
| ttx | Hence "open design" and "open community" | 08:47 |
| ttx | And those four opens proved sufficient, with minor tweaks in the meaning of open community | 08:48 |
| *** tetsuro has quit IRC | 09:39 | |
| *** ricolin has joined #openstack-tc | 09:47 | |
| *** markvoelker has joined #openstack-tc | 09:50 | |
| *** markvoelker has quit IRC | 09:55 | |
| *** rpittau is now known as rpittau|bbl | 10:12 | |
| *** tkajinam has quit IRC | 10:17 | |
| ttx | tc-members: please review https://review.opendev.org/737487 | 10:40 |
| ttx | That formally proposes to remove all bold style from some components from the OpenStack map. | 10:41 |
| *** ricolin has quit IRC | 10:55 | |
| *** e0ne_ has quit IRC | 11:47 | |
| *** lpetrut has joined #openstack-tc | 11:51 | |
| *** markvoelker has joined #openstack-tc | 11:52 | |
| *** markvoelker has quit IRC | 11:57 | |
| *** e0ne has joined #openstack-tc | 11:58 | |
| *** rpittau|bbl is now known as rpittau | 12:14 | |
| *** ricolin has joined #openstack-tc | 12:36 | |
| *** dklyle has joined #openstack-tc | 12:58 | |
| knikolla | o/ | 13:28 |
| njohnston | o/ | 13:36 |
| *** markvoelker has joined #openstack-tc | 13:53 | |
| knikolla | sorry for not being around much last week, i was out sick for the second half of the week. | 13:55 |
| *** markvoelker has quit IRC | 13:57 | |
| jroll | one of my APAC colleagues is wondering if the "Large-scale Usage of Open Infrastructure Software" event next week will be recorded. anyone know offhand? | 14:06 |
| *** e0ne has quit IRC | 14:09 | |
| *** e0ne has joined #openstack-tc | 14:14 | |
| *** bnemec has quit IRC | 14:16 | |
| *** bnemec has joined #openstack-tc | 14:20 | |
| fungi | i think they planned to record all the sessions, but i'll ask | 14:33 |
| *** markvoelker has joined #openstack-tc | 14:39 | |
| *** ricolin has quit IRC | 14:42 | |
| smcginnis | Just noting this here, but dragonflow was retired in November 2018. It is still under the openstack/ namespace. | 14:42 |
| smcginnis | Should that be moved to x/? Wasn't sure what the policy is there. | 14:43 |
| smcginnis | It should like just be retired at this point. Doesn't look like it's active, and I know the people that were working on it were told to stop. | 14:43 |
| *** markvoelker has quit IRC | 14:44 | |
| mnaser | smcginnis: thanks for bringing that up, let me dig into this | 14:46 |
| mnaser | smcginnis: mind if i ask how you noticed this (just so we can capture this if we notice other projects)? | 14:46 |
| mnaser | smcginnis: "only currently or previously-official OpenStack deliverable repositories (or those managed by SIGs, working groups and other officially-recognized bodies) remain within the openstack Git namespace prefix on OpenDev." from https://governance.openstack.org/tc/resolutions/20190711-mandatory-repository-retirement.html | 14:49 |
| mnaser | so in that case, it's okay that it stays under openstack/ but the content shouldn't be there | 14:50 |
| smcginnis | mnaser: I can start the retirement process to close that out. | 14:51 |
| smcginnis | I noticed looking at some of our global requirements and their health. | 14:51 |
| mnaser | smcginnis: i'd appreciate that, in the meantime, i'm going to write a small script to go over all of our repos and see if there's anything that's has anything more than a .gitreview and README.rst file | 14:51 |
| smcginnis | There is a lib that hasn't been updated in 9 years. Only consumer is dragonflow. | 14:51 |
| mnaser | that'll help keep things tidy | 14:51 |
| smcginnis | That would be good to catch those that retired before we had the full retirement process in place. | 14:52 |
| fungi | jroll: the opendev conference organizers confirmed, all the teleconference sessions will be recorded and recordings published shortly afterward | 14:55 |
| jroll | excellent, thanks fungi :) | 14:55 |
| fungi | smcginnis: it shouldn't be moved to another namespace, just need to have its retirement completed in place | 14:56 |
| smcginnis | Yeah, on the retirement process now. | 14:56 |
| mnaser | i have something that will audit all repos too :) | 14:56 |
| fungi | also andreas put together a list recently, auditing what non-completely-retired non-official projects were still in the openstack namespace. it's fewer than 10 now | 14:57 |
| fungi | several were old neutron stadium deliverables | 14:57 |
| fungi | smcginnis: mnaser: i can pull his audit from a few days ago back out of logs, he posted it in here in hopes tc members would care to okay completion of retirement for those | 14:58 |
| fungi | https://etherpad.opendev.org/p/urpGIncRoCLJxJp1Icny | 14:59 |
| fungi | no, wait, that was docs retirement, let me find the other one | 14:59 |
| fungi | 2020-06-15 18:48:17 <AJaeger> And here's a complete list of such repos that are retired but still in openstack namespace: dragonflow networking-l2gw networking-l2gw-tempest-plugin networking-onos openstack-ux python-dracclient solum-infra-guestagent transparency-policy | 15:00 |
| mnaser | i got a couple more too here with my test | 15:01 |
| mnaser | i'll push up something so zuul gates for legacy.yaml changes | 15:01 |
| mnaser | ssome openstack-ansible ones, soem charms too | 15:01 |
| smcginnis | I thought python-dracclient was still used by ironic. | 15:01 |
| fungi | used maybe, but is it a deliverable? | 15:03 |
| fungi | legacy.yaml says python-dracclient: retired-on: 2016-11-28 | 15:03 |
| smcginnis | Well, there was just recently a ML thread on it, and it looks like there has been activity ongoing: https://review.opendev.org/#/q/project:openstack/python-dracclient | 15:04 |
| mnaser | i most definetly remember the thread about it :) | 15:04 |
| fungi | in that case, an official team should adopt it, or it should be retired and forked elsewhere (another namespace in opendev, or somewhere outside opendev) per https://governance.openstack.org/tc/resolutions/20190711-mandatory-repository-retirement.html | 15:05 |
| fungi | optionally i suppose it could become its own project team | 15:05 |
| smcginnis | It looks like it's maybe more accurate to say it's no longer under openstack governance, but it is still an active project. | 15:06 |
| mnaser | yeah that feels like it should be inside x/ | 15:07 |
| fungi | in which case the copy of the repository in the openstack namespace would need to be retired, and then they could fork it somewhere else | 15:08 |
| clarkb | smcginnis: to expand a bit on what fungi said, I think the idea is to fork into x/ once there is development interest. Otherwise we'll just end up with a different dead repo | 15:09 |
| *** belmoreira has quit IRC | 15:09 | |
| fungi | in this case it sounds like there's active development | 15:10 |
| smcginnis | Yeah, I agree. I think the history shows there is development interest, so that's probably what should be done. | 15:10 |
| fungi | but yes, the process would be that openstack retires the repository in its namespace | 15:10 |
| fungi | and then the active developers for the project create the fork as a new project | 15:10 |
| openstackgerrit | Mohammed Naser proposed openstack/governance master: Add legacy repository validation https://review.opendev.org/737559 | 15:10 |
| fungi | (can have the same name, just needs to not be in the openstack namespace any longer) | 15:10 |
| mnaser | ^ this works locally and exposes a list, i made it more gentle to not hit opendev.org as much | 15:10 |
| smcginnis | We could move python-dracclient and other vendor specific things into a dell/ namespace or something like that too, right? | 15:11 |
| smcginnis | It doesn't need to be x/ ? | 15:11 |
| fungi | fork, not move, but yes it could be any namespace | 15:11 |
| fungi | or it could be outside the opendev hosting infrastructure if they prefer | 15:12 |
| smcginnis | But who would prefer that? :) | 15:12 |
| smcginnis | But yeah, could be a GitHub, GitLab, or whatever as well. | 15:12 |
| fungi | some people do! i don't understand it either ;) | 15:12 |
| mnaser | looks like a few retired projects have missed removing .gitreview | 15:13 |
| mnaser | so my 'more than 2 files is not retired' check isn't "as valid" | 15:13 |
| mnaser | i think i would personally be happy at actually removing that .gitignore file to clean it up properly | 15:13 |
| mnaser | so all those repos have 2 files, .gitreview and README | 15:13 |
| mnaser | i guess if we're cleaning it up, might as well as do it right | 15:14 |
| smcginnis | .gitreview is supposed to stay. | 15:14 |
| smcginnis | Not .gitignore. | 15:14 |
| mnaser | yeah there was a charm clean up that dropped gitreview | 15:14 |
| fungi | yeah, the process was updated to say keep .gitreview, because otherwise it makes it harder to push the readme file | 15:14 |
| smcginnis | To be fair, we realized and added that later. | 15:14 |
| mnaser | we're not explicit on README file names i guess | 15:14 |
| smcginnis | Also breaks some automation. | 15:14 |
| fungi | mnaser: we just updated the process to say it needs to be README.rst specifically | 15:15 |
| fungi | because of the new documentation redirects going to it | 15:15 |
| mnaser | ok so lets be strict about that too | 15:16 |
| smcginnis | I seem to recall when we had the PyPi upload breakage when they started enforcing formats, there were at least a handful of repos that decided to use a README.md instead. | 15:16 |
| openstackgerrit | Mohammed Naser proposed openstack/governance master: Add legacy repository validation https://review.opendev.org/737559 | 15:19 |
| mnaser | ok, this is much more strict but if we're cleaning up we might as well get it done | 15:19 |
| fungi | it'll need some gerrit admin help, because once a repository is set read-only it's a manual process to reactivate it so new changes can be pushed | 15:20 |
| fungi | but i'm happy to take care of that part once we have a list | 15:21 |
| mnaser | heres output from a local run: http://paste.openstack.org/show/795106/ | 15:21 |
| mnaser | the non .gitreview ones will be a little annoying | 15:21 |
| mnaser | i will send an email to all the different affected teams on the ML and ask for the cleanup.. then we can try and follow up if any don't get done | 15:22 |
| njohnston | I don't think neutron-vpnaas is retired, am I right about that slaweq? | 15:24 |
| mnaser | this is shaping up to be a very long subject :) | 15:26 |
| mnaser | i'm tempted to throw [all] at this point.. | 15:26 |
| mnaser | "[tc][chef][docs][fuel][[horizon][tact][infra][ironic][neutron][keystone][murano][charms][openstack-ansible]" and i'm not even done, heh. | 15:26 |
| fungi | maybe it could be multiple e-mails, or batched... | 15:27 |
| mnaser | sigh, im trying to make an etherpad and when pasting, the lines all get wrapped into 1-5 lines | 15:28 |
| fungi | but before anyone will be able to push fixes for that, it'll need someone to reactivate the repos in gerrit and probably also need a gerrit admin (or someone we delegate those permissions to temporarily) to merge the changes directly so that there's no need to reintroduce zuul configuration | 15:29 |
| mnaser | yeah i think a direct merge is probably best | 15:29 |
| fungi | we also need to think about whether our manage-projects automation will switch acls back to read-only behind me after i switch them to active, or if it will just not notice (hopefully the latter) | 15:32 |
| fungi | might be good to pick one to try this plan out on ourselves and make sure we know what to expect | 15:33 |
| clarkb | fungi: mnaser I would prefer we didn't do that | 15:34 |
| mnaser | do what exactly? | 15:34 |
| clarkb | instead you write a .gitreview and push with it when you need to push | 15:34 |
| clarkb | resurrect all the .gitreviews. Its just not necessary | 15:34 |
| clarkb | if you reenable a git repo, you add the gitreview back again | 15:34 |
| mnaser | i mean, if we're cleaning all this up for consistency, might as well while we're at it..? | 15:35 |
| fungi | some need other stuff like readme renames | 15:35 |
| mnaser | most non .gitreview repos have a README.md or README | 15:35 |
| clarkb | thats gonna be a big pain to coordinate with gerrit... | 15:35 |
| clarkb | the whole point is that those repos are dead so why bother? | 15:35 |
| mnaser | cant we just have a topic that someone with merge power can force merge these changes when they're free? | 15:36 |
| fungi | we recently worked out that we should be redirecting the docs urls to that retirement readme, which needs to be consistently named | 15:36 |
| clarkb | someone has to manaully click buttons in gerrit, ensure that manage-projects doesn't run while we then push and merge a bunch of changes, then rerun manage projects to resync the RO state | 15:36 |
| fungi | mnaser: the challenging part, as i mentioned, is that you can't push those changes without a gerrit admin reactivating these repos manually | 15:36 |
| fungi | and our automation may go behind us and switch them back to read-only before the changes are pushed and merged | 15:37 |
| clarkb | I guess for me its a lot of effort for something that is dead | 15:37 |
| clarkb | its dead leave it be | 15:37 |
| mnaser | well, we have no way of retroactively making sure we dont add more dead/unretired projects | 15:37 |
| fungi | not normalizing them does make it harder to check new retirements have been completed correctly though | 15:37 |
| mnaser | ^ yep | 15:37 |
| mnaser | fungi: could we flip the RO switch, have manage-projects re-open them, and then lock them back up again after? | 15:38 |
| mnaser | like over a period of 2 weeks or something | 15:38 |
| mnaser | i'll do the patches myself if folks dont end up doing them... | 15:38 |
| clarkb | mnaser: yes we can explicitly merge an acl update to not RO them to keep manage-rpojects from switching it back. Still need a gerrit admin to flip the RO to RW initially though | 15:38 |
| fungi | mnaser: manage-projects can't reopen them, it's a manual process | 15:38 |
| fungi | it can only switch active projects to read-only, it can't switch read-only projects to active because it needs to push a config (acl) change to do that, which being read-only prevents | 15:39 |
| mnaser | oh ok, so it's a technical limitation, not a 'no one wrote the code to do it yet' thing | 15:39 |
| fungi | at least not unless we modify the automation to use the gerrit api to change the project status instead of relying exclusively on acl configs | 15:40 |
| fungi | it comes up so infrequently that it's not made sense to spend time making possible via automation | 15:40 |
| mnaser | https://opendev.org/opendev/jeepyb/src/branch/master/jeepyb/cmd/manage_projects.py is the make-ro code here? | 15:41 |
| clarkb | mnaser: indirectly, that tool applies ACLs to gerrit. YOu can set an ACL to make a project RO | 15:41 |
| clarkb | mnaser: if you do that, you cannot update the ACLs anymore and thus can't set the ACL to RW and switch from there | 15:41 |
| clarkb | instead you need an out of band update from RO -> RW then you can update ACLs again | 15:42 |
| mnaser | right, so you cant push a change to change the ACLs once you've pushed a change to disallow any more changes | 15:42 |
| fungi | right, catch-22 the acl can't be pushed to make the project not read-only becaus the project being read-only prevents pushing the updated acl | 15:42 |
| mnaser | btw im seeing slow loads on high # of files folders with opendev again :( | 15:43 |
| fungi | if we're worried about manage-projects helpfully setting projects back to read-only after we manually activate them, we could temporarily push a change to make them have active acls, then revert it after we're done proposing and merging changes | 15:43 |
| *** lpetrut has quit IRC | 15:44 | |
| fungi | mnaser: can you elaborate? | 15:44 |
| mnaser | oh, it might be a cache | 15:44 |
| mnaser | https://opendev.org/openstack/project-config/src/branch/master/gerrit/acls/openstack took 14 seeconds to load the first time | 15:44 |
| clarkb | mnaser: yes its a cache | 15:44 |
| fungi | we did just upgrade gitea which brought fixes for rendering times of the browse view in repos with lots of files/history | 15:44 |
| clarkb | first time should be expensive like before, then subsequent loads are better | 15:44 |
| mnaser | ok sorry, i *just* understood how something gets marked as retired, we set the acl-config to retired.config | 15:45 |
| mnaser | fungi, clarkb: how about a one time change that changes acls to the same ones for the tc (so we can help merge those changes), and ask for a one time "unlock projects", with a proposed revert waiting once we're done with everything | 15:46 |
| mnaser | this should be a once-and-for-all thing | 15:46 |
| mnaser | if it can be done using gerrit cli/api, i will gladly write out something that can be copypasted | 15:46 |
| clarkb | mnaser: that would work. I don't know if the gerrit cli/api exposes the RO -> RW toggle but it may | 15:50 |
| clarkb | bsaically you're doing an unretire with plan to re retire | 15:50 |
| mnaser | clarkb: is there some instructions written somewhere on how you making them rw so i can try and check reference if there's a cli/api equiv? | 15:50 |
| smcginnis | I didn't think it did, but that might have been an older version of gerrit. | 15:50 |
| smcginnis | The problem was once it was marked RO, it took some manual work to switch it back to RW. | 15:50 |
| clarkb | mnaser: you go to the project admin page and switch the read only option to rw | 15:51 |
| mnaser | ya, i realize its a bunch of annoying work so trying to minimize impact on non-involved parties (opendev) | 15:51 |
| clarkb | in the UI | 15:51 |
| mnaser | https://gerrit-review.googlesource.com/Documentation/cmd-set-project.html | 15:52 |
| clarkb | https://review.opendev.org/Documentation/cmd-set-project.html looks like we have that and it can set it | 15:52 |
| mnaser | --project-state shows ACTIVE/READ_ONLY | 15:52 |
| mnaser | aha, yep | 15:52 |
| clarkb | mnaser: Note you should look at the docs on our instance | 15:52 |
| clarkb | as the docs we host are version specific | 15:53 |
| mnaser | oh yeah, that's using our actual docs, so that's even more accurate | 15:53 |
| clarkb | so even just generating a list of those commands for the projects would help | 15:53 |
| mnaser | so a change and a list of commands | 15:53 |
| mnaser | (so manage-projects doesnt swap back) | 15:53 |
| clarkb | yes, and you'll need to unretire in zuul | 15:55 |
| clarkb | (with noop jobs likely) | 15:55 |
| mnaser | clarkb: can we skip the unretire in zuul bit and allow for an acl that lets us submit changes (just for this?) | 15:56 |
| mnaser | vastly harder to manage the zuul config too in addition of the gerrit one | 15:56 |
| clarkb | you probably can, I've not had to construct such an acl though so not sure what it looks like. That said its all in the same repo so really not that difficutl to write that change | 15:57 |
| openstackgerrit | Mohammed Naser proposed openstack/governance master: Add legacy repository validation https://review.opendev.org/737559 | 15:59 |
| *** rpittau is now known as rpittau|afk | 16:00 | |
| fungi | yep, this is why i suggested we pick one to try first | 16:00 |
| fungi | and see what all the gotchas and optimizations might be before we try to do a large batch | 16:00 |
| *** diablo_rojo has joined #openstack-tc | 16:03 | |
| *** e0ne has quit IRC | 16:06 | |
| *** gibi is now known as gibi_off | 16:11 | |
| *** markvoelker has joined #openstack-tc | 16:40 | |
| *** markvoelker has quit IRC | 16:45 | |
| *** ralonsoh has quit IRC | 17:28 | |
| *** markvoelker has joined #openstack-tc | 17:54 | |
| *** markvoelker has quit IRC | 17:59 | |
| openstackgerrit | Ghanshyam Mann proposed openstack/governance master: Add deprecated cycle for deprecated deliverables https://review.opendev.org/737590 | 18:02 |
| *** markvoelker has joined #openstack-tc | 18:11 | |
| *** markvoelker has quit IRC | 18:15 | |
| *** markvoelker has joined #openstack-tc | 18:21 | |
| *** markvoelker has quit IRC | 18:31 | |
| *** markvoelker has joined #openstack-tc | 20:25 | |
| *** markvoelker has quit IRC | 20:29 | |
| mnaser | clarkb, fungi: enabling gating with noop-jobs prove to be a lot more complicated. https://review.opendev.org/#/c/737636/2 should be ok enough (and i left a set of commands in a paste which can be ran which will unlock all those projects) | 21:32 |
| mnaser | i've also started this etherpad -- https://etherpad.opendev.org/p/tc-retirement-cleanup | 21:34 |
| clarkb | mnaser: you also have to add the project to zuul's config | 21:36 |
| fungi | yeah, i figured we'd be better off bypassing gating for those changes than trying to readd them to zuul | 21:36 |
| clarkb | I'm not sure I'd call that complicated but yes it requires extra steps | 21:36 |
| clarkb | fungi: but then you need to allow people to merge changes | 21:37 |
| fungi | yep, but if he's already making acl changes | 21:37 |
| mnaser | clarkb: it's complicated because i have to ensure they are properly ordered and then mess about yaml stuff to make sure it doesn't mess up the ordering | 21:37 |
| mnaser | and the spacing remains so i dont cause conflicts | 21:37 |
| mnaser | because we have linters to make sure things are alphabetical so i cant just stick it at the end or something | 21:38 |
| mnaser | so its complicated because of the volume of changes needed | 21:38 |
| clarkb | I mean ya this is why I've asserted I think we should just move on :) | 21:38 |
| clarkb | its a lot of effort for little gain imo | 21:38 |
| mnaser | i can try to come up with acls that allow tc members to submit changes.. | 21:38 |
| fungi | there are at least a few we'd need to change anyway to accommodate the docs redirects | 21:39 |
| mnaser | yeah, and i think while we're at it, lets make sure it doesn't get any worse | 21:39 |
| fungi | the way i see it, if there are 10 which need fixing for the docs redirects we should batch them anyway, and 60 is not substantially worse than 10 if you're already batching | 21:40 |
| clarkb | fungi: re acls, yes but someone has to figure out how to write an acl that works and imo thats likely to be more effort than turning on zuul | 21:41 |
| clarkb | you need to undo the all projects config | 21:41 |
| clarkb | and thats always a learning experience | 21:41 |
| clarkb | whereas we know what needs to be done to turn on zuul | 21:42 |
| mnaser | ok, ill write the thing to add noop-jobs. | 21:42 |
| clarkb | fwiw I'm not sure I understand the docs redirect issue. The source file name shouldn't matter because the output is all index.html or whateve rright? | 21:44 |
| clarkb | or are we linking to the raw source file bceuase there aren't doc builds at that point. This may be the bit I was missing earlier | 21:44 |
| mnaser | i want to make sure our repos are clean and tidy so we dont have a retired project like dragonflow with user facing code | 21:44 |
| fungi | clarkb: the latter | 21:45 |
| clarkb | as an alternative you could redirect them all to a single location that says "this has been retired" | 21:45 |
| gmann | or user facing doc | 21:45 |
| mnaser | and the way to do that is to test that, and the way to test that is to normalize all the existing badly retired ones and clean them up | 21:45 |
| fungi | clarkb: we're redirecting /latest to opendev.org/.../README.rst | 21:45 |
| mnaser | i'm doing my best here to make it the _least_ amount of work possible on others | 21:45 |
| clarkb | fungi: but we could redirect /latest to https://docs.openstack.org/retired.html ? | 21:45 |
| fungi | clarkb: reason being, some of the readmes will indicate that the project has moved elsewhere | 21:46 |
| fungi | not all of them give the same reasons for retirement, and some leave forwarding addresses | 21:46 |
| mnaser | like telemetry | 21:46 |
| gmann | yeah redircted to repo README.rst which has more history why it was retired | 21:46 |
| clarkb | mnaser: while that may be the case this is an awful lot of work for things that we said we were done wiht :/ | 21:46 |
| mnaser | i'm doing it all | 21:46 |
| clarkb | mnaser: no you can't | 21:46 |
| mnaser | and i'm okay with doing it all | 21:46 |
| clarkb | you're doing a good chunk of it though so thank you | 21:47 |
| mnaser | all you have to do is copy and paste a command at this point | 21:47 |
| mnaser | i have a list of comands to copy and paste into your terminal | 21:47 |
| mnaser | that's all i need | 21:47 |
| fungi | i'll volunteer to handle the gerrit admin piece (already did volunteer) and review the config changes for it | 21:47 |
| mnaser | i'll do the noop jobs | 21:47 |
| mnaser | http://paste.openstack.org/show/795110/ i have this | 21:47 |
| clarkb | I'm starting to think we shouldn't make the repos RO | 21:47 |
| clarkb | and keep noop jobs configured for retired repos | 21:48 |
| clarkb | then set up an acl that lets the TC push code rather than registered users | 21:48 |
| fungi | well, we want people to get a clear failure when trying to push changes for retured repos (except for basically this specific circumstance) | 21:48 |
| clarkb | because the next time we need to change something we don't want to do this again | 21:48 |
| clarkb | fungi: yes that is possible with an acl | 21:48 |
| fungi | good point | 21:48 |
| fungi | we can set it so only a particular group has rights to push to refs/for/refs | 21:49 |
| clarkb | yup | 21:49 |
| fungi | and we do have a central/shared "retired" acl, so we could just update that and do a single pass to switch repos back to active state | 21:49 |
| clarkb | well we'd probably only do this for the openstack retired repos | 21:50 |
| fungi | merits further discussion for sure | 21:50 |
| clarkb | at least if the openstack tc is the special updater group | 21:50 |
| gmann | single retired acl make sense and have some openstack admin in that instead of TC | 21:50 |
| gmann | otherwise TC end up handling all those repo management tasks. | 21:51 |
| clarkb | gmann: who do you mean by "openstack admin" ? | 21:51 |
| clarkb | the point I'm trying to make is that from the opendev perspective we've done exactly what was requested and properly retired the repo so it cannot be used | 21:52 |
| clarkb | but what users really want seems to be a soft retire | 21:52 |
| clarkb | and we can do that instead, but it requires the involved gorup (in this case the tc) to take on some potential management tassk | 21:52 |
| mnaser | it's probably once in a blue moon when we decide to do something like this | 21:53 |
| clarkb | sure but once is enough imo | 21:53 |
| gmann | i am not sure who we need new group? | 21:53 |
| fungi | to be clear, members of the community have noticed that our retirement process could be more thorough, and was also far less thorough in the past, so there's a desire to more thoroughly retire some repos which were less thoroughly retired before | 21:53 |
| clarkb | fungi: well they are thoroughly retired from the stand point that you cannot push or merge any new code | 21:53 |
| mnaser | ok, so then do we set all current retire projects to state active and update teh retired.config acl to include tc who can also merge code too? | 21:53 |
| mnaser | so that we don't have it inside the zuul config with noop-jobs forever | 21:54 |
| fungi | clarkb: right, but not necessarily from the standpoint of replacing the repository content, or redrectingthe current urls for their documentation | 21:54 |
| mnaser | we'll either need an acl that allows a certain group to push and submit _or_ we'll have to play add-and-remove noop jobs | 21:54 |
| clarkb | mnaser: I was thinking just leave the zuul config there | 21:54 |
| clarkb | mnaser: its alread ya step in retiring to switch to noop jobs | 21:54 |
| clarkb | so you'd do that then stay there | 21:54 |
| clarkb | with an acl update that prevents registered users from pushing | 21:55 |
| gmann | i will say we cleanup the existing one now and later TC take care the complete-retirement before approving the retirement | 21:55 |
| mnaser | i mean, i'd think that removing it from zuul to reduce the amount of repos we're loading is.. a good impact | 21:55 |
| fungi | some of these repos never had their content removed and replaced by a readme file explaining that they were retired, most of them don't yet have documentation redirects to that readme and we need to normalize the filename to be able to more conveniently provide that | 21:55 |
| clarkb | mnaser: if they are retired properly there is no config to load other than what is in project-config | 21:56 |
| fungi | mnaser: i don't think it really reduces much. retired repositories account for <10% of our total repository count in opendev today | 21:56 |
| mnaser | sure -- maybe then to reduce config we should just have noop-jobs inside system-required | 21:56 |
| fungi | (i checked recently for unrelated reasons) | 21:56 |
| mnaser | i cant remember if that's skipped if other jobs exist | 21:56 |
| clarkb | mnaser: its not | 21:56 |
| mnaser | ah okay | 21:56 |
| mnaser | so we'll maintain that config | 21:56 |
| mnaser | i dont know if we're trying to solve something that will ever happen again because we're going to be gating on it | 21:57 |
| mnaser | and maybe if it comes up again, then it's time to 'solve it for good' and implement a whole process | 21:57 |
| clarkb | mnaser: I'm just thinking ahead to where people decide we need markdown instead of rst | 21:57 |
| clarkb | or an actual html document so it renders nicely | 21:57 |
| mnaser | clarkb: then we won't have to hit improperly retired projects, but all of them, and that's a different activity involving more people | 21:58 |
| clarkb | its the same process though | 21:58 |
| mnaser | i'd argue doing it for all retired is easier than some retired | 21:58 |
| clarkb | I'm just saying it seems like we want a softer retirement | 21:58 |
| clarkb | we can do that | 21:58 |
| mnaser | agreed | 21:59 |
| mnaser | another thing i caught is some projects aren't running the retired.config | 22:00 |
| mnaser | we'll catch those on the flip back and i'll add the governance-validate-legacy to catch them | 22:00 |
| mnaser | hopefully this safeguards us from all this extra work | 22:00 |
| gmann | mnaser: including proejcts.yaml with deprecated flag | 22:01 |
| mnaser | gmann: yeah i saw some chef cookbooks | 22:01 |
| gmann | bcz they also should have clean retirement on master | 22:01 |
| fungi | to be clear about what we're currently trying to solve though, there was recently a great example where someone stumbled across an ironic deliverable which was retired four years ago, back before we began replacing repository content, they found the /latest documentation we published, and the opendev.org hosted source code which they assumed the openstack community still supported. turns out the vendor | 22:02 |
| fungi | was continuing maintenance of that software elsewhere, but it was a very bad experience for the user because they spun their wheels looking at obsolete code which in no way indicated it was no longer expected to be usable | 22:02 |
| fungi | we've learned a lot in the last four years about how to better retire a project, but we owe it to our users to apply that knowledge to things we did a less stellar job of retiring in the past | 22:03 |
| clarkb | fungi: ya the chicken and egg of docs publishing on a retired repo is what got me tripped up | 22:04 |
| gmann | true, we have doc redirect step documented now. | 22:04 |
| clarkb | But I think this ultimately poinst to having such a forceful retirement as being a problem | 22:04 |
| fungi | also to clarkb's point, i think we'll learn even more about it in the next four years, and need to make more improvements to how we've retired projects up to now | 22:04 |
| clarkb | we can't anticipate all future issues | 22:04 |
| clarkb | fungi: exactly | 22:04 |
| mnaser | should we just soften up retirement now? | 22:05 |
| fungi | it seems like a reasonable approach to me | 22:05 |
| clarkb | mnaser: if we decide to do that then yes I think we should. You'll be able to address the known problems today then also any future problems | 22:06 |
| clarkb | you know whats extra funny about this? | 22:06 |
| mnaser | all that requires is setting all retired projects to ACTIVE, updated retired.config and once that lands it should apply the right acl | 22:06 |
| clarkb | we had a bug in jeepy that prevented us from switchingacls on retired projects for a couple of yeras | 22:06 |
| clarkb | that was only recently fixed | 22:06 |
| clarkb | if we found this issue a couple months ago it would have been trivially fixed :) | 22:06 |
| clarkb | mnaser: yup | 22:06 |
| mnaser | ha, your sensed this :) | 22:06 |
| * mnaser still feels like retired.config should allow submit so we dont clobber our already-immense zuul config | 22:07 | |
| fungi | oh, yeah, right, it was filtering to only apply acl changes to non-retired repos, but determined that by looking at the config, so it didn't apply the retired config when we retired the repo | 22:07 |
| clarkb | mnaser: if you can figure out how to construct that acl that should be fine. I think the tricky bit is working around what is in all projects | 22:07 |
| fungi | you could likely just set owner to tc-members | 22:08 |
| mnaser | i think if i can give the tc ability to verified +2 and submit, then we'll be able to +2 and submit option should be available automagically | 22:08 |
| fungi | owner permission grants essentially everything | 22:08 |
| fungi | even the verified and code review +2 and workflow +1 requirements are part of the configuration. you could make that optional as well | 22:09 |
| fungi | but doing that will necessitate some experimentation | 22:10 |
| mnaser | yeah, my idea is pretty much allowing us to merge the same way infra sometimes force merges things | 22:10 |
| clarkb | fungi: owner is weird because a lot of its perms are only available through the web ui and not git/ssh | 22:12 |
| clarkb | fungi: that likely does mean submit is fine though | 22:12 |
| gmann | but that is only for post-retirement-cleanup right. bcz retirement process of merging the repo cleanup is pre step of modify the retired.acl in project-sonfig | 22:12 |
| clarkb | but git push or branch creation/deletion may be trickier | 22:12 |
| gmann | config | 22:12 |
| clarkb | gmann: yes | 22:12 |
| mnaser | gmann: yeah pretty much once it goes 'retired', the project is controlled by tc | 22:12 |
| gmann | can we make it a first step like during noop jobs? and governance approval in project.yaml as first step. so it will be 1. first TC approve the retirement and then volutneer do the retirement steps and TC can keep merging the things. | 22:14 |
| gmann | because governance approval also after repo cleanup and that can go messy is TC does not approve the retirement for any reason. | 22:15 |
| gmann | that is why we have seen projects-config patch as depends-on vs needed-by mixup | 22:15 |
| clarkb | gmann: yes, I think that change can probably happen too though it is somewhat orthogonal. Thats a policy decision vs a "gerrit technical requirement | 22:16 |
| gmann | something like 1. tc retire-approved 2. repo steps of code cleanup etc 3. tc mark retirement-complete | 22:17 |
| mnaser | fungi, clarkb: should only tc members be allowed to push changes? if so, that leaves the bulk of the clean up on us | 22:18 |
| fungi | though as we've seen here, retirement is never really "complete" ;) | 22:18 |
| mnaser | (but we could technically change the acls temporarily) | 22:18 |
| clarkb | mnaser: some subset of users should be allowed to push changes | 22:18 |
| clarkb | mnaser: otherwise people will run git review and it will succeed and it will appear the repo is still in use | 22:18 |
| fungi | mnaser: it would make some sense, yes. either the tc or some group delegated by the tc (tact sig?) | 22:18 |
| * smcginnis would volunteer for any special cleanup team | 22:18 | |
| smcginnis | Janitor SIG FTW. | 22:18 |
| * fungi finds smcginnis a broom | 22:18 | |
| mnaser | does the tact-sig have an acl group right now? | 22:19 |
| clarkb | mnaser: no | 22:19 |
| gmann | tact sig is good idea i think than TC | 22:19 |
| fungi | it doesn't have any formal membership currently | 22:19 |
| mnaser | ah, i'll keep it at tc members for now, the nice thing is we could thoretically open it up and close it back up for x period of time during this cleanup | 22:19 |
| fungi | so we'd need to declare some set of folks the openstack janitors or whatever, but it could make sense as a tact sig activity | 22:19 |
| * mnaser hopes to figure out getting the acls to work first | 22:21 | |
| fungi | the openstack janitors could be a subset of overall tact sig activity in the same sort of way that the vmt is technically a subset of security sig activity | 22:21 |
| fungi | s/technically/officially/ | 22:21 |
| fungi | but yeah, i'm not in any hurry to design more bureaucracy right now | 22:22 |
| fungi | we have plenty already ;) | 22:23 |
| mnaser | remote: https://review.opendev.org/737649 gerrit: change retired.config acls | 22:23 |
| mnaser | fungi: ^ i guess if that looks sane to you (and clarkb) -- perhaps next step is to unlock all retired repos (i can get you a command easily if needed) and merge that? | 22:23 |
| clarkb | mnaser: I think you need to make a new openstack-retired.config file so that you aren't responsible for all retired repos on opendev | 22:25 |
| mnaser | clarkb: that file is openstack/retired.config | 22:25 |
| fungi | i concur | 22:25 |
| clarkb | mnaser: ya but its used by everyone | 22:25 |
| mnaser | so perhaps we should just have non-openstack project point at foo/retired.config later (with the same config, going to some other group?) | 22:25 |
| *** markvoelker has joined #openstack-tc | 22:25 | |
| clarkb | mnaser: ya that also works | 22:25 |
| mnaser | i just dont want to play with too many things if i dont know that config works 100% yet | 22:26 |
| gmann | mnaser: you wan to change this too - https://review.opendev.org/#/c/737636/2/gerrit/projects.yaml | 22:26 |
| mnaser | cause we'll probably ask each tenant/ns for their own retired group i guess | 22:26 |
| clarkb | mnaser: I wouldn't bother. I'd just keep everyone else at the same old retired config for now | 22:26 |
| mnaser | gmann: nope we're taking another route with https://review.opendev.org/#/c/737649/1 -- it's pretty much changing the whole retired project to go to another group | 22:26 |
| fungi | i don't dispute the retired acl is currently in the openstack directory, i just agree it's something we should fix/split | 22:26 |
| mnaser | fair enough :) just wanted to make sure if it was a housekeeping task to do my work all the way | 22:27 |
| fungi | we could probably make a top level retired.conf not in any subdirectory | 22:27 |
| gmann | mnaser: oh, i see you are updating the same file listed in project.yaml 'openstack/retired.config' got it | 22:28 |
| mnaser | gmann: so one a project is retired, it's not read only, it's just with a different acl that only allows a certain group to push changes to it (in this case tc).. effectively keeping it 'retired' but easily ... 'unretireable' | 22:28 |
| mnaser | yep | 22:28 |
| openstackgerrit | Kendall Nelson proposed openstack/governance master: TC Guide Follow Ups https://review.opendev.org/737650 | 22:28 |
| clarkb | mostly retired | 22:28 |
| fungi | just git mv to gerrit/acls/retired.config and update all the references in projects.yaml in one change, then introduce a new gerrit/acls/openstack/retired.config in the next change and switch the openstack retired repos to that (or do it in the same change, though you don't get the reviewability of git mv) | 22:28 |
| mnaser | fungi: so in that case, non-openstack retired projects will remain readonly, correct? | 22:29 |
| fungi | mnaser: right | 22:29 |
| clarkb | jeepyb/utils.py: if entry.get('acl-config', '').endswith('/retired.config') <- we'll want to keep the / prefix if possible | 22:29 |
| clarkb | which maybe means opendev/retired.config would be better | 22:29 |
| fungi | we only want to ultimately change the acl of openstack retired repos | 22:29 |
| openstackgerrit | Kendall Nelson proposed openstack/governance master: TC Guide Follow Ups https://review.opendev.org/737650 | 22:29 |
| fungi | clarkb: oh, good point, we don't put the full repo path in the projects.yaml | 22:30 |
| fungi | and good catch with jeepyb there | 22:30 |
| *** markvoelker has quit IRC | 22:30 | |
| fungi | otherwise we'd have to update it for a re.match() or something so we can cover the non-namespaced one | 22:31 |
| fungi | clarkb: actually we were doing acl-config: /home/gerrit2/acls/openstack/retired.config so not namespacing it would also have been fine | 22:37 |
| fungi | but putting it in opendev for now works too | 22:37 |
| clarkb | ah | 22:37 |
| *** tosky has quit IRC | 22:42 | |
| *** clarkb has quit IRC | 22:44 | |
| mnaser | clarkb, fungi, gmann: https://review.opendev.org/#/c/737652/ https://review.opendev.org/#/c/737654/1 and https://review.opendev.org/#/c/737649/2 should be the kit. the first two changes are pretty much noop and we can land them without much fallout. the last one is the one that needs to be tested | 22:49 |
| mnaser | knikolla: we have gathered some feedback for you at https://review.opendev.org/#/c/722399/ :) perhaps when you're free you can take a shot at making the adjustments to your comments | 22:51 |
| *** tkajinam has joined #openstack-tc | 22:53 | |
| *** clarkb has joined #openstack-tc | 22:58 | |
| *** jamesmcarthur has joined #openstack-tc | 23:04 | |
| *** jamesmcarthur has quit IRC | 23:07 | |
| *** markvoelker has joined #openstack-tc | 23:29 | |
| *** markvoelker has quit IRC | 23:34 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!