19:01:29 #startmeeting infra 19:01:30 Meeting started Tue Oct 6 19:01:29 2020 UTC and is due to finish in 60 minutes. The chair is clarkb. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:01:31 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:01:33 The meeting name has been set to 'infra' 19:01:42 #link http://lists.opendev.org/pipermail/service-discuss/2020-October/000102.html Our Agenda 19:01:49 #topic Announcements 19:02:10 PTG and Summit happen this month. Register now if you haven't already and plan to attend (it is free to register) 19:02:29 The OpenStack release happens next week which we should keep in mind for service changes 19:02:47 and finally Rax hosted db outages around 03:00-05:00 UTC Friday including those for review and grafana 19:03:52 Thats thursday evening around here and Friday morning for ianw I think. I'll try to be around so that ianw isn't the only one at a keyboard if gerrit or grafana get sad 19:04:59 heh, yeah that's a good time for .au for things to go wrong :) 19:05:17 #topic Actions from last meeting 19:05:24 #link http://eavesdrop.openstack.org/meetings/infra/2020/infra.2020-09-29-19.01.txt minutes from last meeting 19:05:28 We recorded no actions 19:05:33 #topic Priority Efforts 19:05:41 #topic Update Config Management 19:05:50 Any configuration management updates to call out? 19:06:36 graphite got swapped out and the old server deleted thanks to ianw's tireless effort 19:07:01 well i haven't deleted the old server yet, but it has been a week so i'll probably do it soon (on my todo list :) 19:07:25 oh, right, deleted it from the inventory 19:08:02 hrm, it looks like that got a -2 for a job that passed in check but failed gate ... https://review.opendev.org/#/c/755150/ ... will look into that 19:10:05 #topic OpenDev 19:10:52 Lets start with gitea. We discovered that setting descriptions errors in a very small portion of requests. I've made the description update non fatal in our repo management if it fails, we'll get to it on another pass (it is fatal if project creation breaks) 19:11:11 I also updated the gitea config to log tracebacks on those errors so that if it happens again we can hopefully debug it further than it broke 19:11:26 so it intermittently fails? 19:11:33 I have confirmed the new config setting is functional and we get tracebacks when starting gitea and the mysql server isn't listening on tcp yet 19:11:45 corvus: yes the error message we get indicates the cache returns an unexpected nil value 19:11:50 like, it's not that some project has a pile of poo emoji in the description and that one always fails? 19:11:51 k 19:11:54 correct 19:12:26 * ianw has a new idea for the dib project description :) 19:12:34 though i can think of a few of my projects which probably deserve a pile of poo as a description 19:12:43 ianw beat me to it 19:14:15 On the gerrit upgrade side of things fungi and I have been doing pair programming ops style and got review-test into shape mimicing a gerrit 2.13 as of october 1. We then upgraded it to 2.16 pre notedb migration using the process described at https://etherpad.opendev.org/p/gerrit-2.16-upgrade 19:14:28 That server is now up and running and you can test it at https://review-test.opendev.org 19:14:49 * diablo_rojo sneaks in late 19:15:04 we also timed the relevant steps so we can gauge how much downtime we'll likely incur for them 19:15:07 The next thing I'm working on is the notedb migration and 3.x upgrades. I've found that we need 3.1 and 3.2 images so am working on that next. While doing that I expect we'll leave 2.16 up like that so people can interact with it 19:15:38 the reason for the notedb migration and 3.x stuff happening next is we want data to determine if we should do a 2.13 -> 3.x upgrade or just 2.13 -> 2.16 then later 2.16 -> 3.x 19:15:59 As expected things like our hacky js CI results table do not work in either the old ui or the polygerrit ui on gerrit 2.16 19:16:05 also if folks have any observations/concerns about the 2.16 deployment there, please add them to the notes section at the bottom of the etherpad 19:16:28 more suprisingly the zuul comment commentlink config does not work under polygerrit and fomr what I've been able to debug cannot be made to work without changing how zuul comments 19:16:44 huh :( 19:16:57 the issue being that gerrit finds the url that zuul posts and treats that separately to other strings which you can regex match on 19:17:03 either things we'll need to address before the production upgrade, or things we might want to look into fixing after upgrading 19:17:10 https://gerrit.googlesource.com/gerrit/+/refs/heads/stable-2.16/polygerrit-ui/app/elements/shared/gr-linked-text/link-text-parser.js#268 is the code that does that in gerrit 19:17:30 we could fix that by having zuul not leave comments with urls then do comment link rewrites to urls ourselves 19:17:37 yeah, basically no commentlink matching if the pattern covers an existing url in the content 19:17:42 I also checked that code through 3.2 and I believe its just as broken there as 2.16 19:18:08 in positive news the upgrade itself went pretty smoothly 19:18:10 well, zuul needs to leave usable comments without commentlinks 19:18:17 so i think they have to have urls 19:18:22 corvus: ya and it does, so I'm ok with just ignoring that 19:18:33 they aren't as pretty but they are usable imo 19:18:34 i also don't think the commentlinks really buy us a lot for the zuul comments anyway 19:18:55 another neat thing is gerrit annotates comments that leave -1's and -2's so the zuul comments jump out in the comment list 19:19:02 so the issue is that we can't modify the link to replace the anchor text with the job name? 19:19:03 making it easy to find them and figure out what is broken 19:19:17 corvus: we can't have a regex that matches a url 19:19:34 corvus: and the end result is what you describe 19:19:54 well, i'm unclear about whether the problem is that we can't match a url or we can't modify the anchor text 19:20:01 I can match either side of the url but not the url itself 19:20:24 like, if the comment were "jobname {url}" would we be able to match the interior of the {} and change the anchor text of the resulting url? 19:20:34 and it's matches on the raw comment string minus the url, not the baked comment html 19:21:16 corvus: thats a good qusetion, we can test that by leaving some comments manually and trying to match them with commentlinks 19:21:46 corvus: I expect that if we manually leave such a comment and it doesn't get rendered to an href then we could use commentlinks for that but if the inner bit of {} gets rendered to href we can't 19:21:53 we may however wind up with an href object string inside an escaped version of our attempt at adding an href object, but worth a try 19:22:27 i think it would be in scope to update zuul's comment syntax to make it parseable with commentlinks in newer gerrit, i think the only restriction is we need to make it sensible without commentlinks 19:22:36 <a href=" corvus: ++ 19:46:58 so i have started up a new server in vexxhost 19:47:30 i have merged the borg change with the idea to apply it to this server 19:47:46 nice 19:48:03 looking at the help-wanted section of our specs index (which already includes the auth spec), the irc bot consolidation might be good to drum up interest for as well 19:48:12 it's been not top priority but i'm making progress :) 19:48:51 ianw: one thing I've noticed recently with borg locally is that pip installing borg on arm64 is a bit of a pain for all the reasons we've been having python build time issues in other places 19:49:02 not an issue for us today as we don't need to backup and arm64 hosts but somethign to keep in mind 19:49:20 and the python ecosystem is slowly getting better about that in part due to your work so yay 19:50:07 #topic Open Discussion 19:50:14 Any other items to bring up today? 19:52:41 sounds like that may be it. Thank you everyone 19:52:58 Feel free to bring up discussions on the mailing list or in #opendev 19:52:59 thanks clarkb! 19:53:03 #endmeeting