Monday, 2021-08-02

*** marios is now known as marios|ruck05:38
*** jpena|off is now known as jpena07:00
*** frickler_pto is now known as frickler07:14
*** rpittau|afk is now known as rpittau07:15
fricklerianw: from backlog I gather that you were waiting for me to return, but I'm not sure what I should do now07:22
ianwfrickler: hey there; hope you had fun!  the only thing was checking if you had anything on before i removed it07:47
ianwfungi/clarkb: re that removes wheel setup on centos-8-stream.  builds work @
ianwI have added volumes to publish those; however i need some more work on the slug generation to make sure it generates the right volume name to release in the publish jobs. 07:55
ianwunfortunately for volume-character length reasons its mirror.wheel.cent8s<x64|a64> which doesn't fit the simple template we have, and also current ansible doesn't pick up stream correctly in its facts07:56
*** gibi_pto is now known as gibi08:00
*** sshnaidm_ is now known as sshnaidm08:20
*** ykarel is now known as ykarel|lunch08:34
opendevreviewAndy Ladjadj proposed zuul/zuul-jobs master: [ensure-python] install python version only if not present
opendevreviewAnanya proposed opendev/elastic-recheck master: Run elastic-recheck in container
*** ykarel|lunch is now known as ykarel10:10
opendevreviewKendall Nelson proposed opendev/system-config master: Setting Up Ansible For ptgbot
*** jpena is now known as jpena|lunch11:30
opendevreviewTristan Cacqueray proposed opendev/system-config master: Add gerritbot-matrix health check and expose prometheus monitoring
*** jpena|lunch is now known as jpena12:28
opendevreviewKendall Nelson proposed opendev/system-config master: Setting Up Ansible For ptgbot
opendevreviewTristan Cacqueray proposed opendev/system-config master: Add gerritbot-matrix health check and expose prometheus monitoring
opendevreviewAnanya proposed opendev/elastic-recheck master: Run elastic-recheck in container
fungiianw: the x64/a64 convention already came up because i had to shorten a volume name, so i don't have any objection with fitting whatever you can manage to disambiguate it from other platforms13:13
fungiit's a very tight length limit anyway, only so much we can do13:14
diablo_rojoclarkb, fungi would you mind giving this a look when you get a sec?
*** ykarel is now known as ykarel|away14:16
fungidiablo_rojo: thanks for the heads up, i didn't realize you'd pushed that14:22
clarkblooks like the review cert refreshed successfully over the weekend14:47
clarkbdiablo_rojo: yup I can take a look.14:52
clarkbinfra-root I'm also hoping to tackle the gerrit known hosts change and have it manage gitea known hosts as well. Basically make it mergeable and have it cover the known needed entries14:53
clarkbfungi: diablo_rojo: I +2'd that but didn't approve as I think this is our first new list addition after rewriting the list management. Is there anything else we should be checking before we land the change (this is primarily directed at fungi)14:55
clarkbif not maybe fungi you want to approve it when you are able to help monitor it go in (I should be able to watch it all day)14:55
fungiclarkb: it took a day or two for the script to stop complaining about the review cert after it renewed, so i expect there was (and might still be) one or more apache workers hanging onto the old one15:04
fungibut i agree we haven't had any more alerts about it in the past 24 hours15:05
fungiand yeah, i can't think of anything else we want to check on the list creation side of things, but i'm happy to monitor it and troubleshoot after the change deploys15:06
fungiapproving now15:06
fungiclarkb: diablo_rojo: oh, actually i just spotted a problem with that change15:08
fungisee inline comment, i don't think the admin address is valid15:08
fungidiablo_rojo: if you have a minute to fix that up to what you want it to be, i'm happy to reapprove15:08
opendevreviewClark Boylan proposed opendev/system-config master: Improve gerrit known_hosts management
clarkbThat feels too easy, but maybe it is that simple to get gitea and gerrit known_host keys managed on review15:21
clarkbfungi: also if you get a chacne today can you take a look over the next set of proposed gerrit account cleanups?15:22
clarkbI think this should be the second to the last batch with the last batch being fixed in a large commit to push back to gerrit15:23
*** jpena is now known as jpena|off15:25
clarkbI'm also working on getting the merge rollups for ianw's mariadb and my openid fix in gerrit proposed/landed. I don't want to forget about that and have us udpate to fixed 3.2 then upgrade to 3.3 or 3.4 and regress15:40
*** diablo_rojo is now known as Guest307416:08
corvusi'm making the gerrit synapse user16:11
corvustristanC, clarkb, mordred: when i create a user with EMS, it also supplies me with an access token (device id "-").  i guess we could use that?  or would it be better to create a new device and get a new access token?16:13
mordredcorvus: I'm not sure16:14
clarkbcorvus: I'm ok using the default access token if that makes things easy.16:14
corvusclarkb: it is easier, but not by much (it's just a curl command to get a new device+token)16:15
corvuswe're testing -- let's try out the default token and see what happens :)16:16
opendevreviewKendall Nelson proposed opendev/system-config master: Add mailing list for FLOSS MOOC
corvusi don't see a way to get an access token through the ui after creating the account16:20
corvusso that's probably a one-time thing16:20
*** rpittau is now known as rpittau|afk16:24
corvusi added the matrix token and approved the matrix eavesdrop changes16:24
*** sshnaidm is now known as sshnaidm|afk16:25
*** marios|ruck is now known as marios|out16:26
opendevreviewClark Boylan proposed opendev/system-config master: WIP Prepare gitea 1.15.0 upgrade
clarkbI noticed whe nwe did the 1.14 upgrades that there is a 1.15 release candidate. This is prep work to be ready for that release16:32
opendevreviewMerged opendev/system-config master: Add matrix-eavesdrop container image
clarkbha ok my known_hosts  fixup change exposes a fun thing with our testing and prod deployment. If we use group vars in testing and host vars in prod all on the public side of things then the public host vars override the test specific group vars16:43
clarkbI think this has a relatively simple fix, move the prod stuff into a group var file from a host vars file. But something to be aware of I guess16:43
corvusclarkb: yeah, the intent is they should be the same16:45
corvusanything on bridge should be in a .j2 file in system-config16:45
corvusplaybooks/zuul/templates/groupvars/gitea.yaml.j2 in system-config should have the same variables as /etc/ansible/hosts/groupvars/gitea.yaml on bridge16:47
corvusexcept with underscores :)16:47
corvus * `playbooks/zuul/templates/group_vars/gitea.yaml.j2` in system-config should have the same `variables as /etc/ansible/hosts/group_vars/gitea.yaml` on bridge16:47
clarkbya it gets weird where we have publicly defined things that need to be different in each16:47
clarkbin this case the known_hosts keys are different sets because talking to the test node is different than the prod node16:49
clarkbI suspect this means we are also writing out a prod replication config in the test setup but then that fails as it doesn't have the right ssh keys to do anything with that16:49
fungibecause of differences in secret data16:50
clarkbfungi: ya16:50
fungii wonder if we should be stashing the "public" counterparts of the secrets with the secret data instead16:50
corvusfungi: yeah, i think that might be a good solution16:50
corvusyou can't change the public key without changing the private one :)16:50
fungithat way the testing equivalents of them can be committed together as well16:51
corvusand i believe we have started storing some public keys in secret ansible vars16:51
clarkbya that is one solution16:51
clarkbI'll redo my change to operate under that assumption16:51
fungiit's not ideal, i don't especially like putting non-sensitive material in the secret store, but when there's a technical reason to do that because it simplifies things, i think it's an acceptable tradeoff16:52
corvusfungi: if it helps soften the blow, keeping related data together makes maintenance easier :)16:52
fungiyes. yes it does16:52
opendevreviewClark Boylan proposed opendev/system-config master: Improve gerrit known_hosts management
clarkbthat modifies the known_hosts management but then only sets up values in system-config for the test env. After (or before I suppose) we merge that we can add the contents for prod from the previous patchset to the private vars16:54
clarkbI expect that will pass testing and be mergeable if reviewers are happy with it16:54
opendevreviewMerged opendev/system-config master: Run matrix-eavesdrop on eavesdrop
opendevreviewMerged opendev/system-config master: Run matrix-gerritbot on eavesdrop
clarkbHPE reports an interesting issue around gerrit mergability checks. TL;DR for us is do not force merge a change if gerrit errors when determinining mergability for that change. You'll cause that error to be present on all changes17:06
clarkball changes in the repo (or maybe just branch on that repo)17:06
clarkbya I think the important thing to take from this is if gerrit has fundamental errors then force merging is only going to cause more problems17:09
clarkbits ok as long as you keep them contained to a specifi cchange. Just make a new one constructed differently17:09
fungiyeah, basically you don't want those to be on a tracked branch17:09
clarkbthe gitea build fails. I guess it is a good thing we are testing this early.17:19
opendevreviewMerged opendev/system-config master: Add mailing list for FLOSS MOOC
clarkbI think that maybe the issue is due to a new nodejs release?17:26
fungii'll check in a bit to see if the deploy for that ^ does what we expect17:26
opendevreviewClark Boylan proposed opendev/system-config master: WIP Prepare gitea 1.15.0 upgrade
clarkbtrying a different nodejs version though they all got updated a couple of days ago17:29
clarkbI'll file an upstream bug with gitea if this seems persistent17:29
clarkbnodejs 12 seems to build gitea just fine. I'll let that run through fully to idnetify any othe rissues but then revert back to nodejs 16 and if that fails file a bug upstrema17:55
clarkbI think upstream is using nodejs 14 despite the changelog saying they use 1618:04
clarkbI'll actually do another followup that uses 14 to gather that info. But I suspect the pin of alpine to 3.13 is pinning nodejs to 14.17.4 which may be working but 16.6.0 is not18:05
clarkb12.22.0 appears to work too18:05
mordredclarkb: ++18:06
clarkband the reason they pinned alpine is really interesting
clarkbwhich takes us to
clarkbwe should avoid these issues because buster isn't that new but a really interesting interaction18:16
fungiyeah, if we switch to bullseye we may want to double-check that18:19
fungii see linked in there talking about bullseye18:19
clarkbits not clear to me if you need to explicitly enable seccomp features or if they are enabled by default in such a way that things break. It seems like they may be enabled by default18:21
clarkbfungi: good news is our testing should check things for us I think? Maybe not to that depth though. But we'll build with all the same docker and kernel and so on as prod and can inspect that I suspect18:22
fungiif it prevents gitea from running then yeah18:22
clarkbit breaks something to do with git pushes18:23
clarkband our test job does push sytem-config in there for verification purposes18:23
clarkbit takes the local system-config that the test is running off of and puts that into gitea18:23
fungiahh, yeah18:23
opendevreviewClark Boylan proposed opendev/system-config master: WIP Prepare gitea 1.15.0 upgrade
clarkbthe previous patchset did fail functional testing. Looks like anonymous cloning failed?18:38
clarkbbut it built which is good enough for now18:38
tristanCcorvus: the default access token should work just fine18:39
clarkbya it failed to serve the robots.txt too18:40
clarkbuser redirect does not exist [name: robots.txt] <- is the error message18:52
clarkband we get unauthorized for the diskimage-builder clone18:53
clarkbMove (custom) assets into subpath `/assets` (#15219) <- I wonder if that is related to the robots.txt issue18:54
clarkb that does mention robots.txt18:56
opendevreviewJay Faulkner proposed openstack/diskimage-builder master: Permit specification of extra bootstrap packages
clarkbI think favicon handling might not be working in gitea, but I'll need to hold a node to be sure.19:08
opendevreviewClark Boylan proposed opendev/system-config master: WIP Prepare gitea 1.15.0 upgrade
clarkbtime for lunch then I'm going to file a bug about the nodejs 16 issue then check if favicons are broken holding for ^ and file a bug for that if so19:13
clarkbianw: fungi: separately it would probably be good if we can host the opendev logo for lodgeit and for gerrit theming directly on thoes servicesso that we don't have to do a dance with them19:14
clarkbianw: fungi: if you can look into that that would probably be good. The diff for the ps above captures where those will need to be updated19:14
clarkb(I mention you since I htink you added them to the respective systems)19:14
fungiinfra-prod-base failed in deploy on autoremoving packages from static0119:23
fungigrub-install: error: cannot find EFI directory.19:23
fungithe workaround was creating efi mounts on servers?19:24
fungiyeah, looks like we've added "LABEL=UEFI /boot/efi vfat defaults 0 0" to fstab on other servers19:25
fungishould i do the same to static01?19:25
Clark[m]Does that device exist? If it doesn't then that may break the ability to boot?19:31
fungiwell, obviously i'd test mounting it from the shell ;)19:36
fungi/dev/xvda15     105M  8.9M   96M   9% /boot/efi19:37
fungilooks like it does19:37
clarkbthen ya I expect that would fix it19:43
fungii'm going to manually re-run `apt-get autoremove -y` there now to make sure it's no longer bailing with an error19:44
fungiSetting up grub-efi-amd64-signed (1.167~18.04.5+2.04-1ubuntu44.1.2) ...19:45
fungiInstallation finished. No error reported.19:45
fungiexit code was 019:45
fungiso that seems to have solved it now19:45
fungilooks like that was the only failure logged from the job, so it should be back to passing on the next deploy19:46
fungialso infra-prod-service-lists is finally building now19:46
fungi already shows a floss-mooc ml19:46
fungidiablo_rojo_phone: ^ hopefully you've received an initial message with the admin login for that19:47
fungii have a feeling the job is going to time out. the last thing ansible logged is that it's running "TASK [mailman-list : Create the site list if it doesn't exist]" 15 minutes ago19:59
fungilooks like there's a newlist command in the process table on the lists server since all that time too20:00
fungiroot     20094  0.0  0.3  57016 15740 pts/0    S+   19:44   0:00 /usr/bin/python /usr/sbin/newlist floss-mooc knelson@...20:01
fungiwhy is that hanging?20:01
clarkbis it trying to prompt for a password? or maybe it wants the user to ack it via email?20:01
fungistrace on that process shows it's on a read()20:02
clarkbfungi: the one thing we change between testing and prod is that we don't allow testing to send the email notifications20:02
fungiyeah, i bet that's it, probably didn't pass the right option to newlist, checking the manpage now20:02
clarkb has been filed20:03
fungii suspect you're right that it's prompting for a password nobody will ever be there to enter20:03
clarkbfungi: we should be passing it on the command line though iirc20:03
fungiwe are, it's showing in the command line string in the process table20:03
clarkbbut ya maybe something with the command construction20:03
clarkblike we need an extra flag? I dunno20:03
funginewlist [options] [listname] [listadmin-addr] [admin-password]20:03
fungi(from its manpage)20:03
fungi"You can specify as many of the arguments as you want on the command line: you will be prompted for the missing ones."20:04
fungibut yeah, the three required parameters are on the command line20:06
fungiwe don't pass any options, but that should be fine?20:06
clarkbfungi: unless we need to pass an option. testing passes the don't send email option20:07
clarkbmaybe there is a positive send email option we need to specify?20:07
clarkband we are being prmopted to specify whether or not we want to do that?20:07
clarkbfungi: ya the --quiet option says that it supresses a prompt20:15
clarkbI bet that is it20:15
clarkber wait is that for mailman3 though?20:15
clarkb"Normally the administrator is notified by email (after a prompt)  that  their  list has been created.  This option suppresses that notification and the prompting"20:16
clarkbthat is indeed in mailman2. How was puppet doing it if not prompting? Maybe it was feeding the prompt a response?20:16
fungii'm looking at the newlist manpage on lists.o.o20:16
fungiso not mailman320:17
fungibut that much seems to be the same20:17
clarkbMy strong hunch here is that testing works because we pass --quiet becuse we don't want to email people every time we run the tests. But when we create a new list for real we do want to email them20:17
fungithe options newlist claims to support here at --language --urlhost --emailhost --quiet20:18
fungilooks like not passing those should be fine20:18
clarkbyes, but it prompts if you don't pass --quiet20:18
clarkbalso note the list was created lending more evidence to the idea that it is simply prompting about sending the notification20:18
clarkbthat is really annoying that it doesn't have a just send the email flag20:18
fungimmm, yes20:19
clarkbI think the old puppetry must've repsonded to that prompt20:19
clarkband now we aren't20:19
fungiyeah, i suspect so, digging up the source for that module now20:20
fungii don't see where it's interacting with the process there, just building up the command line20:22
clarkbfungi: I think line 91 calls the process20:23
fungiright, but not seeing where it would interact with it after calling20:24
clarkbya it would likely need to be some sort of ruby magic in the provider type's handling of the commands list?20:25
fungithe newlist command is still hanging on the server, but the job timed out20:28
clarkb`stdin =[:stdinfile] || null_file, nil, 'r')`
fungihere's another possibility... could the ssh options be doing something which causes the process to simply not terminate due to inherited descriptors?20:28
clarkbfungi: I suspect the ansible playbook is still running20:28
clarkbfungi: no I strongly suspect that we are being prompted to confirm we want to send the email20:29
clarkbfungi: it seems that current puppet at least provides an explicit nil stdin which probably bypasses all that?20:29
fungii guess if we </dev/null that would work?20:29
clarkbfungi: it might, I have held nodes for testing mailman stuff we can test it on. I suspect we'll need to kill the newlist and cause that ansible playbook run to clean itself up though20:30
fungiand yeah, could be newlist attempts to perform tty detection and ansible is fooling it into thinking there's a user at the other end of the pipe20:30
clarkbyes exactly20:31
fungi</dev/null is the usual way around that sort of smartness20:31
clarkbfungi: you'll need to convert the command task to a shell task to do that. I wonder if ansible has a flag to do that20:32
clarkbfungi: is a possible alternative20:32
fungiyeah, i just tested and it does prompt to hit enter to send the notification20:33
clarkbfungi: did you test that on my test node or the prod server? note I think it will actually create the list for you even though the command is prompting20:34
fungiand if i tack on /dev/null it skips right on past the prompt20:34
fungiyes, i created a test list on there and set it to notify my personal addy20:34
fungiand then tested again with a different listname and the null stdin20:34
clarkbcool just wanted to point out if testing on the prod server that you need to clean it up.20:35
fungireceived both notifications20:35
fungii did not test on production, no ;)20:35
clarkbfungi: ok that gives us a method to fix things for future newlist runs. What do we think we want to do for the process on the prod server? If we kill it I'm not sure if other newlist tasks will compelte20:35
clarkbI suppose we can kill it, then manually delete the list. Fix ansible then rerun the playbook20:36
fungiso anyway, i'm now fairly certain that 1. it's hanging at the hit enter to notify prompt, and that if we can figure out how to set stdin to /dev/null it will work as intended20:36
clarkbfungi: setting stdin to /dev/null is easy in the ansible. Just change the command task to a shell task and add that bit to the command string20:36
fungiyes, i think killing the newlist process will likely be all we need to do, if the last step it performs is the notification. i can just notify diablo_rojo_phone of the initial password after double-checking the list is really there and has an initial config20:37
clarkbfungi: ok20:37
fungiclarkb: alternatively, do command tasks have an option for setting the file descriptors on them in ansible itself?20:37
clarkbfungi: see my link above looks like you can give it a string value20:38
clarkbfungi: looks like you could set stdin to '' and ansibel will append a newline to that by default20:38
clarkbfungi: maybe test that ^20:38
clarkbjust create a file with a newline in it for that and < file into the command?20:39
fungiyeah, that works too20:40
fungijust tested, and it notified me20:40
clarkbin that case I think you can add stdin: '' to the command task20:40
fungicreated a file named newline that was just a linefeed character and then added <newline20:40
clarkbI expect that will mimic what ansible does via the string20:41
fungiit does look like the floss-mooc ml was successfully created and i'm able to browse its configuration in the webui after logging in with the admin password i see on the command line for the hung process20:43
clarkbyay to testing. I think our rename playbook doesn't work with gitea 1.15.0 and that is why I'm failing now20:43
fungii've passed the initial pw for the floss-mooc ml to diablo_rojo_phone out of band20:46
fungii killed the newlist command and ansible seems to have wrapped up the task for it now20:47
opendevreviewJeremy Stanley proposed opendev/system-config master: Skip notification prompt for newlist command
fungiclarkb: ianw: ^20:53
*** dviroel is now known as dviroel|out20:53
fungiclarkb: is proposed-cleanups.20210727 (73 lines) the one you want sanity-checked?20:54
clarkbfungi: yup and there should be a corresponding audit file20:59
clarkbfungi: note an unrelated change snuck into 80326321:00
clarkbfungi: left notes on that change21:01
clarkb"Repository transfer has to be confirmed, if user can not create repo for new owner (#14792)" I wonder if the determination for that has changed in 1.15.021:04
opendevreviewJeremy Stanley proposed opendev/system-config master: Skip notification prompt for newlist command
fungiclarkb: ^ thanks for spotting!21:04
fungino clue how that happened21:04
fungii might have inadvertently hit the checkout button in gertty or something21:04
clarkbfungi: did you see the notes on the other file?21:04
funginot yet but fixing now21:05
opendevreviewJeremy Stanley proposed opendev/system-config master: Skip notification prompt for newlist command
fungiclarkb: ^ and fixed, thanks again!21:06
opendevreviewClark Boylan proposed opendev/system-config master: Use nodejs 14
clarkbthat change should be mergeable and is better reflection of how things are built upstream21:11
opendevreviewClark Boylan proposed opendev/system-config master: Improve repo rename functional testing
clarkband that adds a bit more testing around renames that I noticed we should probably have while trying to debug the failed rename with gitea v1.15.0-rc221:13
opendevreviewJames E. Blair proposed opendev/system-config master: Remove comment from matrix-eavesdrop dockerfile
corvusi'm self-approving that so we can get an image build21:23
corvus(due to a misconfiguration since fixed, we have not yet run a promote job followed by an upload job for that image)21:24
opendevreviewClark Boylan proposed opendev/system-config master: WIP Prepare gitea 1.15.0 upgrade
clarkbthat rewrites things in the rename playbook to use the gitea rest api to trasnfer and rename repos21:34
clarkbI don't actually know if that will work but I suspect that if I submit a bug saying hacking the web ui to transfer and rename things doesn't work anymore we'll get laughed at and pointed to the api :)21:35
clarkbif the api doesn't work then we can file bugs against it21:35
clarkbianw: it seems we need to prune backup02. Do we just run the script for that? I also notice it has review-dev contents on it that may be deletable?21:36
clarkbI need to work on the meeting agenda shortly. Please add your entries there for tomorrow21:37
clarkbinfra-root does pass testing. If you can review it and it gets some +2's I'll modify the private vars to include the known hosts we want in production before we land it21:40
corvusclarkb: i think with that zuul stack under control i can take a look at that now (istr i did some of the original work on that -- but maybe the rest api wasn't fleshed out enough at the time)21:48
clarkbcorvus: ya I think there may be some other places we can do similar cleanups, but right now my goal is largely just to get the v1.15.0-rc2 release happy (so that we are prepared for that release)21:49
clarkbcorvus: generally converting to the api where we can seems like a good idea though21:50
corvusclarkb: ++ on all21:50
corvusclarkb: i want to say it was specifically the transfer method that didn't exist at the time?21:50
clarkbcorvus: that wouldn't suprise me. It does seem to be in the current swagger doc though21:51
opendevreviewClark Boylan proposed opendev/system-config master: Skip notification prompt for newlist command
clarkbfungi: ^ fixed up an ansible format problem there22:04
ianwclarkb: ok, yep we can just run the script to prune backup, but yeah i can look at cleanup of review-dev first22:06
clarkbnot sure if any of the review-dev stuff is worth keeping, that server had been largely unused once review-test happened22:08
corvusianw, mordred: can you take a look at the comment i wrote in about the containerfile image builds22:09
ianwwe fiddle resolv.conf in project-config elements right?22:12
ianwthere has been stuff about resolv.conf being symlinks, etc. in the past and i'll have to context switch it back in22:13
clarkbagenda sent. I'm going to dive into some zuul reviews now22:14
ianwis what i'm thinking of22:15
corvusianw: aha, so that's what's making it work -- but containerfile or fedora-containerfile wouldn't work without that22:17
corvus(and since that's in openstack/project-config -- that's not ideal for an element in DIB itself)22:18
corvusianw: i think the best thing to do for an ubuntu:focal image would be to create the symlink in an early finalize.d script, then that project-config script could override it (just as it does for debootstrap builds)22:20
corvusianw: what do you think about doing that in general, and if it's a good solution, do you think it should be in ubuntu-containerfile, or should we put it in containerfile?22:21
ianwi'll have to think about it an page back in the thinking behind the .ORIG file copy22:22
clarkbI marked WIP so that we don't accidentally land that change before the 1.15.0 gitea release happens22:40
opendevreviewMerged opendev/system-config master: Remove comment from matrix-eavesdrop dockerfile
corvusianw: thanks; hopefully those notes help -- i found grepping a build log for 'resolv.conf' helped too.23:25
corvusianw: theres good comments on the intention behind .ORIG -- it just understandably didn't take into account the idea that both the base image would have a garbage resolv.conf and the case where there are no installs after that to fix it.23:27
clarkbinfra-root I think and are safe cleanups/improvements to the gitea building and testing process. The first one will cause a new image to be built and deployed though. I'm happy to approve that when I can watch it if ya'll prefer23:29
clarkbbut would be good to land those then we'll be in a good spot to rebase the v1.15.0 change on that and get even more better testing23:29
clarkbfungi: passes testing now23:36
fungithanks for the fix-up!23:49
opendevreviewJames E. Blair proposed opendev/system-config master: matrix-eavesdrop: fix initial room path creation

Generated by 2.17.2 by Marius Gedminas - find it at!