19:01:12 #startmeeting infra 19:01:12 Meeting started Tue Mar 22 19:01:12 2022 UTC and is due to finish in 60 minutes. The chair is clarkb. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:01:12 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:01:12 The meeting name has been set to 'infra' 19:01:41 I'm on my laptop today and realized I dont have my typical notes an dthe desktop is off so I couldnt' copy them off. Will do my best :) 19:01:54 #link http://lists.opendev.org/pipermail/service-discuss/2022-March/000326.html Our Agenda 19:02:03 We do have an agenda though and we'll be following that 19:02:12 #topic Announcements 19:02:44 The openstack yoga release is about a week away. As usual exercise judgement/caution when making changes to avoid impacting that process. That said we updated gerrit to get some bugfixes as well as gitea so it doesn't mean no changes 19:03:15 and kernel security fix reboots 19:03:28 and zuul 5.1.0 19:03:37 yup. Basically use your judgement and exercise caution. 19:03:52 to be fair, we've been constantly updating zuul anyway 19:04:33 we upgraded from almost-5.1.0 to the commit which got tagged as 5.1.0 19:04:44 Also the next ~2-3 weeks are super busy for me. I've got family in town, kids are on spring break, openstack release, PTG, I actually have to go to the dmv etc 19:05:07 Pleaes do ping me if something urgent or important comes up and I'll do my best to help, but my hours and availbaility will be weird for the next bit 19:05:56 good luck! 19:06:18 thanks 19:06:21 #topic Actions from last meeting 19:06:30 #link https://meetings.opendev.org/meetings/infra/2022/infra.2022-03-15-19.01.txt Last weeks minutes 19:06:34 There were no recorded actions 19:06:49 i don't think we really do actions any more 19:06:58 we could just drop this section 19:07:09 we do occasionally and they are worth calling out when they happen but ya if we don't have them then maybe just skip ahead 19:07:12 #topic Topics 19:07:17 which I'll do now :) 19:07:29 hah 19:07:29 #topic Improving CD throughput 19:08:21 I don't know there has been much movement on this 19:08:40 nope, still on the todo list! 19:08:46 I was thinking if we did want to make use of some ptg time this topic might be worthwhile, but we can discuss with an adhoc meeting or in review easily enough too 19:09:00 #topic Container Maintenance 19:09:14 I hvaen't seen any movement on this since the insecure ci registry got updated. 19:09:39 jentoio: are you still interested in doing more of these? if so is there anything I can do to help? 19:09:41 I recently started a new role so have been distracted. I should have some time to look at this week 19:10:07 congrats! 19:10:09 I guess mariadb are next? 19:10:15 thanks 19:10:17 and thanks for helping! 19:10:20 jentoio: no there are a few more services that should get dedicated users first 19:10:50 as long the etherpad indicates what to work on, I can start on it this week 19:10:51 mariadb is less important because it has a semi dedicated user its just less ideal. 19:11:07 jentoio: noted. I'll try to update the etherpad with some order of operations thoughts 19:11:14 and yes thank you for the help 19:11:36 glad to help 19:11:50 #topic Cleaning up old reviews 19:12:09 We managed to retire a bunch of repos and abandon their open changes. Since then I've started looking at the list of changes in system-config 19:12:43 I've tried to do two things there. First is abandon any change sthat clearly no longer apply. The other is to rebase/refactor/update changes which are still likely helpful but have grown stale 19:12:53 #link https://review.opendev.org/q/project:opendev/system-config+status:abandoned 19:13:13 that gives you an idea for how many changes we've abandoned. I think it is almost half the total open changes in system-config which is great 19:13:23 #link https://review.opendev.org/q/project:opendev/system-config+status:open+topic:system-config-cleanup2~ 19:13:27 #undo 19:13:27 Removing item from minutes: #link https://review.opendev.org/q/project:opendev/system-config+status:open+topic:system-config-cleanup2~ 19:13:31 #link https://review.opendev.org/q/project:opendev/system-config+status:open+topic:system-config-cleanup2 19:13:39 #undo 19:13:39 Removing item from minutes: #link https://review.opendev.org/q/project:opendev/system-config+status:open+topic:system-config-cleanup2 19:13:42 #link https://review.opendev.org/q/project:opendev/system-config+status:open+topic:system-config-cleanup 19:13:44 I can't type 19:14:07 This is the list of changes that I'm trying to revive. They all use the topic:system-config-cleanup topic. If you have time to review thoes that would be great 19:14:40 Additionally if you look over your own changes and find some that can be abandoned that is helpful and if you have old changes that should be landed feel free to update them as necessary and set that topic on them 19:16:01 Not much else on this topic. Its a slow process but we're slowly refining the set of outstanding work to things that actually matter which is nice 19:16:13 #topic Retiring the old Gerrit repo 19:16:25 Once upon a time not that long ago we carried a fork of gerrit 19:17:06 Since the move to Gerrit 3.2 and container builds we've managed to switch to upstream builds of Gerrit. We can use local patches in the build process similar to how distro packaging works to patch stuff if necessary 19:17:31 what this means is we don't need the Gerrit repo anymor eand it can be retired. However, there is some question about what the best way to do that is due to the many branches in the Gerrit repo 19:17:43 ianw: ^ want to explain the options we've got? 19:18:25 the overall important thing is, unlike other repos, we want this one to fall out of search engines 19:19:02 so usually we just leave old branches alone, but here we don't want them coming up before actual gerrit changes when you search for gerrit things 19:19:35 where you := anyone on the internet 19:19:46 so we can delete all the branches 19:20:31 or we can merge a "this repo is retired" commit that deletes everything to all the branches ... but this leaves the change history there to find 19:21:00 or we can leave it, and put some robots.txt in opendev.org to specifically disallow indexing on /opendev/gerrit 19:21:14 I think google has been good about finding those updates and not listing the source code. I am wondering if we should do the normal process and then wait a bit for google to reindex (or figure out how to ask them to reindex quicker) and then we can delete after if still an issue 19:21:35 I'm leaning towards not blocking with robots.txt since it would be a unique situation which we've found are good to avoid 19:21:52 the normal process would be to leave the old branches, but i assume you mean to delete the content on all branches? 19:22:13 ya sorry on master and all the stbale-* branches 19:22:20 i'm also fine with deleting all the branches... our "history" still remains in the form of gerrit change refs which will keep the relevant commits from being garbage-collected 19:22:40 (deleting the branch heads themselves, not simply replacing their content) 19:23:05 ya I'm not against that it just seems lke this is a useful experiment to see if that is necessary 19:23:18 I think we're assuming it is, but knowing with more data would be helpful 19:24:29 progressive changes are mildly inconvenient because setting the acl to read-only state will have to be undone manually to do anything else through gerrit 19:24:38 but it's certainly doable 19:25:13 I think deleting branches is a little bit of an exception to that as you need super privs to do that anyway 19:25:18 but yes in general that is true 19:25:52 tbh i'm sort of tending towards deleting branches too, just so we don't have to revisit 19:25:54 well, actually branch deletion is no longer owner-restricted. it can be delegated, and now is for openstack and one other project i forget at the moment 19:26:09 fungi: oh good point, but I don't think we do that for this repo currently 19:26:20 we don't, but we could 19:26:27 ya if others feel strongly about just deleting the branches I'm not opposed 19:26:46 i could put in the readme a URL to opendev.org that shows the changes in each branch 19:26:50 the content will remain in gerrit, and its usefulness to us is limited now that we are so far ahead and on the upstream code base 19:27:04 to review.opendev.org 19:27:41 the content will remain in gitea too, it's replicated there, you just can't access it through gitea without requesting specific commits or cloning and checking the named change refs out locally 19:28:23 and would i delete and replace the master branch with just a readme? 19:28:32 we never committed anything to that branch, i don't think? 19:28:42 ya I think retiring the master branch as usual would still be good. No we didn't but it is still HEAD iirc 19:29:13 the way the repo is setup is there is a master branch which is likely very stable. A bunch of upstream/foo branches which were not modified compared to upstream. And then openstack/foo which we did modify 19:29:40 deleting master and upstream/* should be lossless due ot upstream having the branches. Then openstack/* will still hae changes recorded in gerrit 19:30:58 I guess if others prefer deleting branches we can proceed with that 19:31:46 my preference is for whatever's simple and handled in a way that other projects could theoretically do without being gerrit admins 19:32:16 so i'm not keen on robots.txt or .htaccess changes on the server to block repo-specific requests 19:32:37 gerrit admins or server sysadmins i should say 19:32:43 heh, there's a remotes/origin/upstream/test-to-delete so something wants to be deleted 19:34:08 so i will delete the origin/* and gerrit/* branches, and point HEAD to a branch with just a README on it? 19:35:06 ianw: I wouldn't update HEAD (there are problems with changing that value) just set the content of whatever HEAD is to a README in it (likely master) 19:35:55 ok, so that's a hybrid approach where we assume the changes in master will fall out of search indexes after we merge a change to delete everything there, right? 19:36:43 yes, I guess the othe ropiton is replacing all of master's history? 19:37:09 it seems like there's gerrit on the master branch, but it stops at "Date: Tue Jun 7 13:41:36 2011 -0700" 19:37:13 I guess the balance here is having enough content to indicate why it exist at all 19:37:31 ianw: ya it was fro mthe original import and then not kept up to date as future owrk happened on brnaches 19:38:04 I would put in the readme left behind there links to review.opendev.org and each branch, that shows the changes we committed 19:38:07 that's a fun memory, we were carrying a gerrit fork almost 11 years ago 19:38:54 so in terms of archaeology, if anyone ever cares, they could pull upstream gerrit, and then those changes that were on the branch, and have something like what was running 19:39:05 yup 19:39:39 it might be worth asking mordred if he has any concerns with that as he set up the forking system iirc 19:39:44 I really doubt it though 19:39:56 and we're well enough past running the fork that it shouldn't matter for ou rday to day 19:39:56 he'll probably volunteer to light the match 19:40:36 so ... the conclusion is to delete all the branches, but leave a readme with sufficient detail to understand what used to be going on in the repo and how we used to run gerrit? 19:40:46 ++ I think that works for me 19:41:58 ok, per the previous conversation you can give me an action item to do that if you like :) 19:41:59 sounds good, thanks 19:42:46 #action ianw delete old gerrit fork branches and leave breadcrumb readme on the existing HEAD branch as preparation to retire and set the repo as read only on review.o.o 19:43:24 we're actiony once more! ;) 19:43:53 #topic Scheduling Project Renames 19:44:32 We have a project rename request. As mentioned earlier my next few weeks are a bit crazy for me to be thinking about renames. I'm personally inclined to punt this until after the ptg as a result. But if others think we can/should do this sooner feel free to work towards that 19:44:57 I think this is the 11-15th timeframe before things quiet down for me 19:45:06 * of April 19:46:42 Maybe pencil in the 15th and if we get organized sooner then graeat otherwise this is the plan? 19:46:50 thats good friday though 19:47:13 that probably means less load (a good thing) but fewer people around possibly to help (less of a good thing?) 19:47:26 I guess we can go with that as the rough schedule and tweak as necessary from here 19:47:37 i feel almost sure we have something booked over that weekend 19:47:52 should we do similar to last time and put the gerrit upgrade to 3.5 in there too? 19:48:05 I don't think we need to. Renames are pretty quick 19:48:25 and I worry if I'm driving it Ill have even less time to prep for that upgrade 19:48:41 (things like the config update to force case sensitive username sare still in review though) 19:48:59 "he'll probably volunteer to..." <- Burn it down! 19:49:22 :) 19:49:47 i'll bring the petrol 19:49:50 anyway I think we can plan for renames on the 15th for now. If we find we are behind we can push that back 19:49:50 clarkb: ok, i'll put on my todo list to go back and look at it all again. i don't mind trying to drive the upgrade bits after i context switch in all the pre-work you've done 19:50:02 ianw: cool that would be helpful 19:50:19 15th is fine with me, thanks 19:50:34 #topic Open Discussion 19:51:09 ianw: https://review.opendev.org/c/opendev/system-config/+/827774 i sthe case sensitivity change 19:51:26 not strictly necessary but a good belts and suspenders and reminder that we are relying on that behavior in production so should test thta way too 19:51:44 i do have somewhere to be over that weekend, surprisingly (an interactive van gogh exhibit), assuming covid doesn't go crazy in the next few weeks 19:51:49 but friday i'm open 19:51:50 it is difficult to test because they won't le tyou create colliding users anymore but that setting allows existing collisions to exist 19:52:54 Anything else? 19:53:36 fungi: is that like https://www.visitvictoria.com/regions/melbourne/whats-on/art-and-exhibitions/exhibitions/van-gogh-at-the-lume-melbourne 19:53:53 clarkb: thanks, will look 19:54:01 ianw: probably similar 19:54:05 looks like it 19:55:03 i thought it was very cool. they must have had 100 projectors, i would have loved to have seen what sort of test-patterns they had to align everything 19:55:07 seemed like an opportunity to go out of town for an overnight trip and do something interesting without too much plague 19:55:51 looks like fun 19:56:20 Also sound slike that may be it? I'll let everyone go then. Thanks! 19:56:25 #endmeeting