Wednesday, 2022-03-16

ianwyeah i was just wondering that ...00:00
ianwi could rm everything on the master branch, but not sure that solves the problem of old changeset pages ranking higher than actual gerrit when searching for specific things00:01
ianwi guess we could explicitly robots remove that repo00:02
opendevreviewIan Wienand proposed openstack/project-config master: opendev/gerrit : retire project
*** dviroel|ruck is now known as dviroel|ruck|Afk00:05
ianwi've abandoned changes; there's no jobs setup, so that retires it from gerrit, i'll take suggestions in there of what we want to do with the actual repo?00:16
opendevreviewIan Wienand proposed opendev/system-config master: gitea: disallow opendev/gerrit
opendevreviewIan Wienand proposed opendev/system-config master: gitea: disallow opendev/gerrit
opendevreviewIan Wienand proposed openstack/project-config master: opendev/gerrit : retire project
*** rlandy|bbl is now known as rlandy|out00:59
opendevreviewIan Wienand proposed opendev/gerrit master: Retire repo
opendevreviewIan Wienand proposed openstack/project-config master: opendev/gerrit : retire project
*** kevinz_ is now known as kevinz02:33
wxy-xiyuanianw: Hi, can I spend your time for the repo sync problem? it looks that openEuler mirror is down from 14th Feb. It sync package from openEuler mirror in Russia. Is that the problem, the internet is blocked?02:45
wxy-xiyuanOr any place I can get the sync error?02:46
ianwwxy-xiyuan: ahhh, yes that might be a problem :/03:07
ianwthe logs are exported @03:07
ianwrsync: failed to connect to ( Connection timed out (110)03:08
ianwi would definitely imagine this has something to do with ... current events03:09
fungiwxy-xiyuan: if there's a different rsync mirror we should be connecting to instead, please propose a change for this line:
ianw doesn't appear to list mirrors 03:11
wxy-xiyuanOK, there are many mirror. I'll change it Singapore one03:11
wxy-xiyuanthe en url seems broken. I'll let openEuler fix it quick. The cn one
wxy-xiyuanThanks for help03:12
opendevreviewMerged zuul/zuul-jobs master: ensure-podman: add containernetworking-plugins
opendevreviewwangxiyuan proposed opendev/system-config master: Fix openEuler mirror problem
opendevreviewwangxiyuan proposed opendev/system-config master: Fix openEuler mirror problem
*** ysandeep|out is now known as ysandeep05:05
opendevreviewMerged opendev/system-config master: Fix openEuler mirror problem
*** arxcruz|off is now known as arxcruz07:50
*** ysandeep is now known as ysandeep|lunch07:54
*** jpena|off is now known as jpena08:01
*** ysandeep|lunch is now known as ysandeep08:38
opendevreviewwangxiyuan proposed openstack/diskimage-builder master: Enable Yum mirror for openEuler element
*** pojadhav- is now known as pojadhav08:54
opendevreviewwangxiyuan proposed openstack/diskimage-builder master: Enable Yum mirror for openEuler element
*** rlandy|out is now known as rlandy10:26
*** ysandeep is now known as ysandeep|afk10:37
*** marios is now known as marios|ruck10:40
*** ysandeep|afk is now known as ysandeep11:16
*** dviroel|ruck|Afk is now known as dviroel|ruck11:16
opendevreviewBenedikt Löffler proposed openstack/diskimage-builder master: Use https for downloading ubuntu images
gthiemongeHey Folks, promote-openstack-releasenotes failed in (after the patch merged), is there anything we can do here?13:19
fungigthiemonge: it's idempotent so will get rerun the next time a change merges to any branch of that repo13:28
gthiemongefungi: ok! thanks! it's not a big deal13:29
fungii haven't looked at the failure, but the most common cause is when uploads of builds triggered by different branches of the same project race one another and the two rsync projects trip over each othe's tempgiles13:30
fungier, and the two rsync processes trip over each other's tempfiles13:32
*** ysandeep is now known as ysandeep|afk13:40
*** rlandy is now known as rlandy|mtg14:00
fungineed to go run some errands now, but should be back by 16:00 at the latest (hopefully sooner)14:04
*** ysandeep|afk is now known as ysandeep|out14:43
*** marios is now known as marios|ruck14:50
*** rlandy|mtg is now known as rlandy15:01
clarkbfungi: when you get back want to +A if then is a good time to help monitor? I expect to be around until lunch and can adjust accordingly so no worries on my side15:14
fungiyep, back-ish already and will approve now while catching up on other things15:15
* clarkb finds breakfast while the gitea change is in the gate15:41
opendevreviewAndy Ladjadj proposed zuul/zuul-jobs master: [upload-logs-base] add public url attribute
opendevreviewAndy Ladjadj proposed zuul/zuul-jobs master: [upload-logs-base] set ContentEncoding only if not 'None'
opendevreviewAndy Ladjadj proposed zuul/zuul-jobs master: [upload-logs-base] add ipa extension to known mime types
opendevreviewAndy Ladjadj proposed zuul/zuul-jobs master: [upload-logs-base] add android mime-type
clarkbfungi: in double checking gitea things I think we will want to check the gitea authorized keys file is updated to point to the new command path (looks like newer gitea added an extra option or two as well)15:54
clarkbfungi: the new gitea 1.16 deployment sets this properly but I'm realized we don't check that it updates it for existing keys. Not too worried about it since gitea has been good about upgrades in the past but calling it out as something to check15:54
opendevreviewAndy Ladjadj proposed zuul/zuul-jobs master: [upload-logs-base] add public url attribute
opendevreviewAndy Ladjadj proposed zuul/zuul-jobs master: [upload-logs-base] set ContentEncoding only if not 'None'
clarkbfungi: /var/gitea/data/git/.ssh/authorized_keys if you want to compare between the test node and production15:56
clarkbmanually editing that shouldn't be too bad either15:56
clarkbif it becomes necessary15:57
opendevreviewAndy Ladjadj proposed zuul/zuul-jobs master: [upload-logs-base] set ContentEncoding only if not 'None'
opendevreviewAndy Ladjadj proposed zuul/zuul-jobs master: [upload-logs-base] add ipa extension to known mime types
fungii guess if it doesn't upgrade appropriately, we should expect gerrit to cease synchronizing commits to gitea?15:57
opendevreviewAndy Ladjadj proposed zuul/zuul-jobs master: [upload-logs-base] add android mime-type
clarkbfungi: yes that would be the impact15:57
clarkbI think our recovery process would be to backup the old file, edit file to use command value and options from testing, possibly restart the services, then trigger replication. Shouldn't be too bad15:58
clarkbif you think its worth trying to test that 1.15 -> 1.16 does this for us we can -W the change before it merges. Or another option would be to put gitea02-gitea08 in the emergency file15:59
fungii'm not too worried about it. worst case we find immediately after rollout that it's wrong, we fix up the location and re-replicate everything16:00
fungithe impact to users will be nearly nonexistent, they'll just not see updates reflected in gitea for a brief period today16:01
clarkb is the related chagne for background16:01
opendevreviewAndy Ladjadj proposed zuul/zuul-jobs master: [upload-logs-base] add ipa extension to known mime types
clarkbfungi: wfm16:01
*** dviroel|ruck is now known as dviroel|ruck|lunch16:02
opendevreviewAndy Ladjadj proposed zuul/zuul-jobs master: [upload-logs-base] add android mime-type
clarkbit does say if we execute the correct path that it should automatically set things for us and my change did cahnge the path16:02
clarkband the test node has the correct value in its authorized_keys file so chances are it will just work16:02
fungipython 3.7.13, 3.8.13, 3.9.11 and 3.10.3 were just tagged. i'll be recompiling for a bit16:03
*** marios|ruck is now known as marios16:04
clarkbin looking at the gitea ssh stuff more closely I've discovered that /var/gitea/data/gitea/avatars is where the avatar files apparently go. I strongly suspect that those are either not in the right format or got lost in production in an update. Chances are if we reset avatars it will find them again after writing them to that dir16:11
fungiyeah, that brokenness may be cruft from an early upgrade which has just been carried forward ever since16:13
fungiwe could test the theory on one of the servers16:13
clarkbfungi: ya we should double check what produces a 404 in the browser when fetching an avatar then cross check against that dir's contents16:15
clarkbthen if the content is missing we could use a test node to try and just replace the file16:15
clarkbor if the content is in the wrong format try to determine teh correct format and convert it16:15
*** frenzy_friday is now known as frenzyfriday16:17
zigoI recieved a voucher for the summit, but it doesn't seem working, there's nowhere to enter the promo code, who should I complain about this?16:22
clarkbzigo: when you register you select the ticket you want and above that is a "enter promo code" option That is where it goes16:23
zigoOh gosh... didn't see ... :)16:24
zigoclarkb: Will I have the pleasure to see you in Berlin, as well as fungi?16:24
fungizigo: that's my hope!16:24
zigoGr8 ! :)16:25
fungipredicting the future is hard even in reasonably certain times, but i'm going to do my best to be there16:25
zigoBTW: My first Yoga VM is up and running (using Bullseye backports), and pings, thanks everyone for this very smooth release! :)16:25
fungii saw the post to the ml, excellent progress!16:25
opendevreviewMerged opendev/system-config master: Update Gitea to 1.16.4
clarkbI'm going to abandon since it seems like we're happy consuming gerrit releases and just trying our best to keep up to date with those rather than master16:27
fungilooks like the deploy for 828184 is already in progress too16:27
fungiwell, the image upload anyway, but the prod service job should start any moment16:28
clarkbfungi: it will just do the image promotion then wait for the hourly jobs to complete. The zuul job is running then eavesdrop, but should be soon16:28
fungioh, yep, though those are nearly done16:28
*** ysandeep|out is now known as ysandeep16:36
clarkbthe gitea job has begun16:42
clarkbit does the load balancer first iirc16:42
clarkbso there is a bit of a delay before it gets to the backends16:42
clarkb just updated16:46
clarkbit updated its ssh authorized keys file so I think that should be good. Still a good idea to double check replication but far less concerned now16:47
*** marios is now known as marios|out16:49
clarkb02 is updated now too16:49
opendevreviewAndy Ladjadj proposed zuul/zuul-jobs master: [upload-logs-base] set ContentEncoding only if not 'None'
clarkbI don't see any obvious errors replicating to gitea01 in the gerrit replication log and I can fetch zuul/zuul-jobs:refs/changes/44/834044/4 which was replicated after the update according to the replication log16:54
clarkbI can fetch that from gitea01 I mean16:54
clarkbthe first four giteas are done.16:55
fungiyeah, it's looking okay to me so far16:55
clarkbOne thing I noticed is that when you have mutliple replications fro the same project it will delay any extras and then check if they are still needed after the first one completes16:56
clarkbI didn't realize the replication plugin was that smart, but that is a nice optimization16:56
*** jpena is now known as jpena|off17:01
clarkball but gitea08 are done now. SHould be complete shortly17:04
fungithe theme definitely changed in production for me after the upgrade too, as expected17:05
funginow it's all light grey and pale green on charcoal17:05
clarkband now 08 is done. I think the playbook is just finishing up stuff and we should be all set17:08
clarkbOnce the playbook ends I can #status log this17:08
clarkb is the other thing on my list that is starting to grow moss. ianw if you get a chance when your day starts to take a look at that it owuld be appreciated17:10
fungii've noticed that the element matrix webclient similarly takes on these colors when i set its appearance to "match system theme" so i guess this is a thing browsers expose17:11
clarkb it was successful17:11
clarkb#status log Upgraded gitea cluster to gitea 1.16.417:11
opendevstatusclarkb: finished logging17:11
fungithanks clarkb!17:11
clarkbfungi: I'm tempted to set one of firefox's more colorful things now and see if gitea attempts to match :)17:12
fungithat would be a good test17:12
clarkbfungi: I've confirmed the behavior chagne with the dark theme in FF but the others all seem to use a bright background and don't really change much17:13
clarkbmy eyes didn't know what to think about "cheese puff"17:13
clarkb"Teal Galaxy" looks interesting but isn't installed and I'm sure I'll disable it within 30 seconds of installing it so won't bother17:14
*** dviroel|ruck|lunch is now known as dviroel|ruck17:15
*** arxcruz is now known as arxcruz|off17:18
clarkbI won't delete the autohold for the test 1.16.4 instance as that may be useful to debug the avatar issues.17:23
*** ysandeep is now known as ysandeep|out17:38
clarkbfungi: I've rechecked and that one should be an easy land17:45
opendevreviewClark Boylan proposed opendev/system-config master: Use add instead of wget to download things for gerrit images
clarkbreally quickly before lunch I've confirmed that the 404'ing images at do not have files in the /var/gitea/data/gitea/avatars dir18:51
clarkbthe files that are in there appear to be PNGs18:51
clarkbI think we can try to manually upload PNGs for those orgs on each of the backends. Or maybe even just copy them into place? Anyway lunch now18:51
fungii think a solution allowing people to contribute logos for those in project-config and supplying a placeholder otherwise could be nice, but it's not critical19:18
clarkbfungi: poking around in the web ui on our test 1.16.4 instance it does appear we can login as root then go to /admin/orgs and click the little edit button for an org19:38
clarkbFrom there you can "choose new avatar"19:39
clarkbBut there is also a "delete current avatar" button. I'm going to try that on the test instance and see if it generates a enw random one for me19:39
clarkbno that set the cirros avatar on the test instance to the opendev logo19:40
clarkboh if I click "Update avatar" without uploading a file it generates a random one.19:40
clarkbfungi: I suspect this means in production the quickest thing to do for now is to do what I just did on the test host. Delete the avatar then click update without a file set to generate a new random one.19:41
clarkbfungi: ianw: maybe one of you want to test that on the test instance and make sure I'm not crazy then we can try on one of the prod giteas19:41
clarkbhttps:// is the test one19:41
fungihow do we login as root, exactly?19:43
clarkbfungi: has directions. In this case you have to use the test credentials in the test groups file in system-config19:44
fungiahh, okay19:46
fungiin inventory/service/host_vars/
clarkbthat won't have the secret in it. Its the zuul template group vars that has it19:47
fungier, yeah, git grep is failing me but i'll find it19:48
fungiokay, managed to log into the test webui19:51
fungiyeah, so it seems to generate deterministic avatars19:53
clarkbfungi: yes it uses an md5sum hash of some sort based on my quick read of some code19:53
fungiclicking "update avatar" on its own does nothing that i can see if the org already has one19:53
clarkbfungi: ya I suspect we'll have to delete the avatar then click the update avatar button19:54
fungibut deleting and updating does remove and restore it19:54
clarkbto force it to forget the current avatar19:54
fungiseems so, yes19:54
clarkbyou know what though19:54
clarkbI wonder if we had set the avatars to relative image file paths for what we host and then pointed it at logos19:54
clarkbthen when we refactored the logo hosting we broke things?19:54
clarkbanyway that seems like something to address in a roll forward fashion after fixing the immediate 404 problem with generated avatars19:55
fungiwe'll also need to repeat it on each gitea server individually19:55
fungior call the relevant api methods maybe19:55
clarkbfungi: another thing I notice is that all of the non working avatars appear to have double digit file paths but the working ones seem to be primarily hash looking file names19:58
clarkbimplying something changed with how gitea generates those19:58
clarkbso it still could be a bug in gitea we tripped over rather than our own reorganization of values19:59
fungipresumably supporting custom logos for avatars would be fairly straightforward if someone ends up wanting to write an implementation, we could simply copy them from a git repo onto the filesystems right?19:59
clarkbfungi: it is probably better to go through the apis for that in case filesystem locations change, but yes potentially20:00
fungioh, i see, if there's an upload api then that makes sense20:00
fungipresumably the same credentials we use to authenticate repository creation from manage-projects could do it20:01
fungier, not manage-projects, but however we automate it20:01
fungigetting spacey, it must be almost dinner time20:02
*** dviroel|ruck is now known as dviroel|ruck|afk20:03
clarkbPATCH /api/orgs/$org seems to allow you to set the avatar url20:05
clarkbnot seeing a delete avatar or regenerate avatar url similar to what those buttons do20:05
fungiwe have 25 orgs, so clicky-clicky 200 times there. not _terrible_20:07
clarkbfungi: and not all of them are broken20:07
fungioh, that simplifies things20:07
opendevreviewMerged opendev/system-config master: Clean up Gerrit image builds
ianwretirement lgtm21:36
opendevreviewMerged openstack/project-config master: Finalize batch of opendev repo retirements
ianwif we can PATCH update the org logos, i guess we might as well update the ansible to copy in a set a "real" logo for those that have it21:49
ianwin *and* set21:49
ianw doesn't list AvatarURL21:54
ianwyeah, i can't really see the code that would set the avatar url in
ianwif err := user_setting.UpdateAvatarSetting(ctx, form, ctx.Org.Organization.AsUser()); err != nil {22:15
ianwso it looks like the web form update "casts" the org to a user and then calls that function.  but it doesn't appear to be exported as an API22:17
ianwthat function just sets in the db "if err := user_model.UpdateUserCols(db.DefaultContext, ctxUser, "avatar", "avatar_email", "use_custom_avatar"); err != nil {"22:19
ianwall the broken image orgs have "use_custom_avatar" set to 122:31
*** rlandy is now known as rlandy|PTO22:31
ianw"old" orgs seem to have a monotonically incrementing "avatar" field22:33
ianw| lower_name       | avatar                           | avatar_email              | use_custom_avatar |22:34
ianw| opendev          | 4                                |                           |                 1 |22:34
ianw| openstack-attic  | 5                                |                           |                 1 |22:34
ianw| cirros           | a320c2a3eb4fb45635ae2d338488f58b |                           |                 1 |22:34
ianwbut then, one we have added recently, e.g. cirros, has it's md5 as the avatar (a320 == echo -n "cirros" | md5sum)22:35
ianw has hte logo22:36
ianwpyca is "27"22:38
ianwand we have a file /var/gitea/data/gitea/avatars/2722:38
ianw        u.Avatar = fmt.Sprintf("%x", md5.Sum([]byte(fmt.Sprintf("%d-%x", u.ID, md5.Sum(data)))))22:41
ianw        if err = user_model.UpdateUserCols(ctx, u, "use_custom_avatar", "avatar"); err != nil {22:41
ianwwhen you upload a custom avatar, it saves the file as "u.ID-$(md5sum data)", then sets "use_custom_avatar"22:41
ianwso, in short, the "avatar" field of the user appears to be just a name of a file on disk in /var/gitea/data/gitea/avatars22:42
clarkbianw: pyca is a working one with the short file path22:47
clarkbI guess we didn't set a custom avatar for tha22:47
clarkbbtu it is old enough to have the old format22:48
ianwyes, but it gets odder22:48
ianwooohhh, i see ...22:48
ianwso, without use_custom_avatar, it seems to hit gravatar22:49
clarkbbut orgs don't have email addrs so that doesn't quite work for orgs?22:49
ianwwe see a logo there because it does22:49
clarkbI don't see a logo there22:49
clarkbI get the hashed thing22:50
clarkbbut also gerrit is a user not a org22:50
ianwyeah, the "identicon" ... sorry, i'm equating that to the logo22:50
clarkbah ok22:50
clarkbianw: areyou sure it is always going to gravatar? if you look in /var/gitea/data/gitea/avatars the files there are pngs22:50
clarkbI haven't copied a png out of there to view it but I assume it is the identicon value?22:51
ianwi think it is *if* the user db has use_custom_avatar==022:51
clarkbI see. If use_custom_avatar == 0 go to gravatar else lookup in /var/gitea/data/gitea/avatars22:52
ianwi think so22:52
clarkbianw: did you see my suggestion that we delete the avatar and then update teh avatar for those orgs? you can test this on the test instance if you like. But that seems to restore the identicon at least. Then we can think about how to set custom logos22:53
ianwi did, but trying to think about how we can not click on all the giteas :)22:53
ianwwe might be able to do a custom script that hits the non-api app end-points to update it22:54
ianwto set custom logos would be a hack, but not hard22:55
clarkbya the old management ansible library did that in the past but gitea has since grown api supprot for all the things it does so we stopped oding that22:55
clarkbbut the history there may show us how to do that again22:55
ianw1) dump logo file in /var/gitea/data/gitea/avatars/<name-of-org.svg>"22:55
clarkbI just think it is likely to be a one off so not too bad to click things22:55
clarkbupdating the avatar url does seem to have an api if you want to set it to somthing else22:56
clarkbianw: -> organization -> PATCH /orgs/{org}22:56
ianw2) run db query avatar="<name-of-org.svg" use_custom_avatar="1" where name="<org>"22:57
clarkboh hrm that only shows avatar url in the response not the PATCH input, maybe they don't accept it22:57
ianwclarkb: yeah, that doesn't seem to actually expose it, see my notes above22:57
clarkbwhy would they put it in the response if it isn't editable...22:57
clarkbianw: re 2) aren't they all already set to use_custom_avatar=1?22:58
clarkbwe get a 404 because the files are not on disk22:58
ianwclarkb: well, yeah, they are22:58
clarkbianw: they aren't on gitea0122:59
clarkb27 is there so pyca works but 4 is not so opendev does not work.23:00
ianwsorry, i think two diferent things -- yes the orgs all have use_custom_avatar=123:00
ianwand yes, i agree the files are not on disk23:00
clarkbI think if we just put a PNG at /var/gitea/data/gitea/avatars/4 that meet the requirements of gitea (let me dig up a link for that) we'll be good23:00
ianwyes, we can do that23:00
clarkb has limits for those files both in pixel dimensions and file size23:01
ianwi'm thinking though since we've figured this all out, we may as well dump a real logo in there for each org, and update the "avatar" field 23:02
clarkbianw: what do you mean by update the avatar field?23:03
clarkbswitch it to the md5sum version?23:03
clarkbbut ya no objections to using real logos23:04
ianwso we've established that in the gitea db that the "avatar" field of the "user" table is just a plain-text file-name to a file in /var/gitea/data/gitea/avatars23:04
ianwso we could dump real logos in there, and have ansible run a manual mysql update of that field during deployment23:05
clarkbright, but why do we need to update mysql is my questions I guess23:05
clarkbthe entries are already all in the db we just have to write a file to the correct location?23:05
clarkbwe'd want md5sum paths for everything if we do that though I guess since the order of the old file format may differ between backends23:06
ianwright, it's to override this old v new thing we've got going on23:06
clarkbgot it23:06
ianwthe old ones have been created with "avatar = uid" i guess, and new ones with "avatar = md5sum(username)"23:07
clarkbthis will work until gitea ends up getting FIPS'd and then we have to sha256sum :) but until then ++23:07
ianwi don't think that will make a difference --- i'd suggest we put the svg/png on disk as the org name, and then just set "avatar = <name>"23:08
clarkbI wonder if that will cause any other problems. I guess not since they already have multiple schemes in there23:09
ianwyeah, i don't think so -- cause it's just a plain-text entry ultimately23:09
ianwthe confusing thing is the way they've setup the default values, which appears to have changed23:10
ianwi'm just looking at how we create orgs now to see if this can work23:10
clarkbcurrently we create orgs entirely through the api23:11
clarkbwe do a listing first and then for each org not already in the listing create it iirc. The other consideration is when we rename projects across orgs eg x/foo to openstack/foo if it ends up creating a new org then this would potentially cross paths with that too23:11
ianwwhere is the list of orgs?23:12
ianwi know i have looked at this all before but i've forgotten :)23:12
clarkbianw: it is generated from openstack/project-config/gerrit/projects.yaml23:12
clarkbthat file is an input to jeepyb on the gerrit side and our gitea-git-repos role on the gitea side23:13
ianwahhh, that's right, gitea-git-repos23:13
clarkbwith renames we give it a rename specific input file since renames are a one shot23:14
clarkbthose are recorded in opendev/project-config/renames23:14
clarkband they are consumed by the rename playbook and the things it calls23:14
ianwwe could do it "out-of-band" ... hit and parse out the usernames23:16
clarkbianw: ya maybe as a followup to gitea-git-repos and a last step of the rename process?23:16
ianwwrite out a file for each org username (if no specific file, use a default place-holder)23:16
clarkbbasically let creation and renaming happen. Then come back around and set logos as appropriate23:16
ianwthat would be idempotent23:16
ianwif any files change, then run the db update query directly on the gitea hosts23:17
ianwto update the avatar field of each username that the logo file changed for23:17
ianwif there was a rename, well we'd just write out it's correct logo on the next run23:18
ianwin the mean time, it would have whatever default one gitea set23:18
ianw(we've established that new logos are setup correctly to the defaults, it's just the old ones that a borked for unknown reasons)23:18
clarkbnote the "default gitea set" is different for each one, but ya it would be a short period then correct23:19
ianwyep, the thing not to have is a broken image at any point, since that looks lame23:19
ianwshould gitea gain a proper api for this, it could be switched from a db update easily23:20
ianwi think that can all work23:21
ianwthe great thing is that can all be done in a speculative fashion thanks to our job setup :)23:21
clarkbyup, that has become super valuable. 23:22
clarkbrelated, any reason to keep my hold for the 1.16.4 test node at this point or should I delete it?23:22
clarkbI think we've run down the details on avatars and sounds like the next step may produce holdable nodes if we need them23:22
ianwyeah, no need for the node i don't think23:25
clarkbianw: thank you for adding checks around being able to set the reviewed flag on files failed on that check and it updates how we install the jdbc driver for mariadb23:27
clarkbtldr our testing is working. THough i don't know why it faield yet I'm sure I did something wrong :)23:27
clarkb"Cannot load JDBC driver class 'org.mariadb.jdbc.Driver'" So I did something wrong with the switch to ADD I guess23:28
clarkb says that you can use a src that is a url. This will need more digging I guess23:30
clarkbmaybe permissions related23:30
ianwhuh, yeah it looks right23:33
clarkb it seems to have run it23:34
clarkbianw: -rw------- 1 root   root   632979 Jan 29  2021 mariadb-java-client.jar23:39
clarkbso ya I need to make that 644 instead23:39
clarkbI'll work on an update23:39
clarkbI've deleted the 1.16.4 autohold23:41
opendevreviewClark Boylan proposed opendev/system-config master: Use add instead of wget to download things for gerrit images
*** ysandeep|out is now known as ysandeep23:46
clarkbricolin: I'm doing cleanup of our old system-config changes and noticed is that still something you would like to change? IF so you'll need to edit instead. Also that won't actually update the list that will23:54
clarkbhave to be done manually after we update the record keeping23:54
clarkbfungi: elodilles I'm going to abandon since the openstack meta project handles that now23:54
clarkber I guess I can wait for you to confirm that is a safe abandonment23:55

Generated by 2.17.3 by Marius Gedminas - find it at!