19:01:12 <clarkb> #startmeeting infra
19:01:12 <opendevmeet> 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 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:01:12 <opendevmeet> The meeting name has been set to 'infra'
19:01:41 <clarkb> 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 <clarkb> #link http://lists.opendev.org/pipermail/service-discuss/2022-March/000326.html Our Agenda
19:02:03 <clarkb> We do have an agenda though and we'll be following that
19:02:12 <clarkb> #topic Announcements
19:02:44 <clarkb> 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 <fungi> and kernel security fix reboots
19:03:28 <frickler> and zuul 5.1.0
19:03:37 <clarkb> yup. Basically use your judgement and exercise caution.
19:03:52 <fungi> to be fair, we've been constantly updating zuul anyway
19:04:33 <fungi> we upgraded from almost-5.1.0 to the commit which got tagged as 5.1.0
19:04:44 <clarkb> 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 <clarkb> 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 <fungi> good luck!
19:06:18 <clarkb> thanks
19:06:21 <clarkb> #topic Actions from last meeting
19:06:30 <clarkb> #link https://meetings.opendev.org/meetings/infra/2022/infra.2022-03-15-19.01.txt Last weeks minutes
19:06:34 <clarkb> There were no recorded actions
19:06:49 <fungi> i don't think we really do actions any more
19:06:58 <fungi> we could just drop this section
19:07:09 <clarkb> 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 <clarkb> #topic Topics
19:07:17 <clarkb> which I'll do now :)
19:07:29 <fungi> hah
19:07:29 <clarkb> #topic Improving CD throughput
19:08:21 <clarkb> I don't know there has been much movement on this
19:08:40 <ianw> nope, still on the todo list!
19:08:46 <clarkb> 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 <clarkb> #topic Container Maintenance
19:09:14 <clarkb> I hvaen't seen any movement on this since the insecure ci registry got updated.
19:09:39 <clarkb> jentoio: are you still interested in doing more of these? if so is there anything I can do to help?
19:09:41 <jentoio> I recently started a new role so have been distracted. I should have some time to look at this week
19:10:07 <clarkb> congrats!
19:10:09 <jentoio> I guess mariadb are next?
19:10:15 <jentoio> thanks
19:10:17 <fungi> and thanks for helping!
19:10:20 <clarkb> jentoio: no there are a few more services that should get dedicated users first
19:10:50 <jentoio> as long the etherpad indicates what to work on, I can start on it this week
19:10:51 <clarkb> mariadb is less important because it has a semi dedicated user its just less ideal.
19:11:07 <clarkb> jentoio: noted. I'll try to update the etherpad with some order of operations thoughts
19:11:14 <clarkb> and yes thank you for the help
19:11:36 <jentoio> glad to help
19:11:50 <clarkb> #topic Cleaning up old reviews
19:12:09 <clarkb> 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 <clarkb> 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 <clarkb> #link https://review.opendev.org/q/project:opendev/system-config+status:abandoned
19:13:13 <clarkb> 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 <clarkb> #link https://review.opendev.org/q/project:opendev/system-config+status:open+topic:system-config-cleanup2~
19:13:27 <clarkb> #undo
19:13:27 <opendevmeet> Removing item from minutes: #link https://review.opendev.org/q/project:opendev/system-config+status:open+topic:system-config-cleanup2~
19:13:31 <clarkb> #link https://review.opendev.org/q/project:opendev/system-config+status:open+topic:system-config-cleanup2
19:13:39 <clarkb> #undo
19:13:39 <opendevmeet> Removing item from minutes: #link https://review.opendev.org/q/project:opendev/system-config+status:open+topic:system-config-cleanup2
19:13:42 <clarkb> #link https://review.opendev.org/q/project:opendev/system-config+status:open+topic:system-config-cleanup
19:13:44 <clarkb> I can't type
19:14:07 <clarkb> 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 <clarkb> 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 <clarkb> 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 <clarkb> #topic Retiring the old Gerrit repo
19:16:25 <clarkb> Once upon a time not that long ago we carried a fork of gerrit
19:17:06 <clarkb> 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 <clarkb> 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 <clarkb> ianw: ^ want to explain the options we've got?
19:18:25 <ianw> the overall important thing is, unlike other repos, we want this one to fall out of search engines
19:19:02 <ianw> 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 <fungi> where you := anyone on the internet
19:19:46 <ianw> so we can delete all the branches
19:20:31 <ianw> 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 <ianw> or we can leave it, and put some robots.txt in opendev.org to specifically disallow indexing on /opendev/gerrit
19:21:14 <clarkb> 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 <clarkb> 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 <ianw> 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 <clarkb> ya sorry on master and all the stbale-* branches
19:22:20 <fungi> 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 <fungi> (deleting the branch heads themselves, not simply replacing their content)
19:23:05 <clarkb> ya I'm not against that it just seems lke this is a useful experiment to see if that is necessary
19:23:18 <clarkb> I think we're assuming it is, but knowing with more data would be helpful
19:24:29 <fungi> 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 <fungi> but it's certainly doable
19:25:13 <clarkb> 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 <clarkb> but yes in general that is true
19:25:52 <ianw> tbh i'm sort of tending towards deleting branches too, just so we don't have to revisit
19:25:54 <fungi> 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 <clarkb> fungi: oh good point, but I don't think we do that for this repo currently
19:26:20 <fungi> we don't, but we could
19:26:27 <clarkb> ya if others feel strongly about just deleting the branches I'm not opposed
19:26:46 <ianw> i could put in the readme a URL to opendev.org that shows the changes in each branch
19:26:50 <clarkb> 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 <ianw> to review.opendev.org
19:27:41 <fungi> 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 <ianw> and would i delete and replace the master branch with just a readme?
19:28:32 <ianw> we never committed anything to that branch, i don't think?
19:28:42 <clarkb> 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 <clarkb> 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 <clarkb> 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 <clarkb> I guess if others prefer deleting branches we can proceed with that
19:31:46 <fungi> 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 <fungi> so i'm not keen on robots.txt or .htaccess changes on the server to block repo-specific requests
19:32:37 <fungi> gerrit admins or server sysadmins i should say
19:32:43 <ianw> heh, there's a remotes/origin/upstream/test-to-delete so something wants to be deleted
19:34:08 <ianw> so i will delete the origin/* and gerrit/* branches, and point HEAD to a branch with just a README on it?
19:35:06 <clarkb> 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 <ianw> 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 <clarkb> yes, I guess the othe ropiton is replacing all of master's history?
19:37:09 <ianw> 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 <clarkb> I guess the balance here is having enough content to indicate why it exist at all
19:37:31 <clarkb> ianw: ya it was fro mthe original import and then not kept up to date as future owrk happened on brnaches
19:38:04 <ianw> 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 <fungi> that's a fun memory, we were carrying a gerrit fork almost 11 years ago
19:38:54 <ianw> 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 <clarkb> yup
19:39:39 <clarkb> it might be worth asking mordred if he has any concerns with that as he set up the forking system iirc
19:39:44 <clarkb> I really doubt it though
19:39:56 <clarkb> and we're well enough past running the fork that it shouldn't matter for ou rday to day
19:39:56 <fungi> he'll probably volunteer to light the match
19:40:36 <ianw> 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 <clarkb> ++ I think that works for me
19:41:58 <ianw> ok, per the previous conversation you can give me an action item to do that if you like :)
19:41:59 <fungi> sounds good, thanks
19:42:46 <clarkb> #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 <fungi> we're actiony once more! ;)
19:43:53 <clarkb> #topic Scheduling Project Renames
19:44:32 <clarkb> 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 <clarkb> I think this is the 11-15th timeframe before things quiet down for me
19:45:06 <clarkb> * of April
19:46:42 <clarkb> Maybe pencil in the 15th and if we get organized sooner then graeat otherwise this is the plan?
19:46:50 <clarkb> thats good friday though
19:47:13 <clarkb> that probably means less load (a good thing) but fewer people around possibly to help (less of a good thing?)
19:47:26 <clarkb> I guess we can go with that as the rough schedule and tweak as necessary from here
19:47:37 <ianw> i feel almost sure we have something booked over that weekend
19:47:52 <ianw> should we do similar to last time and put the gerrit upgrade to 3.5 in there too?
19:48:05 <clarkb> I don't think we need to. Renames are pretty quick
19:48:25 <clarkb> and I worry if I'm driving it Ill have even less time to prep for that upgrade
19:48:41 <clarkb> (things like the config update to force case sensitive username sare still in review though)
19:48:59 <mordred> <fungi> "he'll probably volunteer to..." <- Burn it down!
19:49:22 <ianw> :)
19:49:47 <fungi> i'll bring the petrol
19:49:50 <clarkb> 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 <ianw> 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 <clarkb> ianw: cool that would be helpful
19:50:19 <fungi> 15th is fine with me, thanks
19:50:34 <clarkb> #topic Open Discussion
19:51:09 <clarkb> ianw: https://review.opendev.org/c/opendev/system-config/+/827774 i sthe case sensitivity change
19:51:26 <clarkb> 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 <fungi> 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 <fungi> but friday i'm open
19:51:50 <clarkb> 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 <clarkb> Anything else?
19:53:36 <ianw> 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 <ianw> clarkb: thanks, will look
19:54:01 <fungi> ianw: probably similar
19:54:05 <fungi> looks like it
19:55:03 <ianw> 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 <fungi> seemed like an opportunity to go out of town for an overnight trip and do something interesting without too much plague
19:55:51 <clarkb> looks like fun
19:56:20 <clarkb> Also sound slike that may be it? I'll let everyone go then. Thanks!
19:56:25 <clarkb> #endmeeting