Wednesday, 2024-05-29

*** dasm is now known as Guest789500:38
*** ykarel_ is now known as ykarel07:46
fricklerheads up an git update in ubuntu likely causes failures like https://zuul.opendev.org/t/openstack/build/ec8d4d066c9941f7a2f270a811bd7e9d12:42
fungifor some reason i thought that had already been addressed years back in some jobs13:05
jrosserthis is new / different https://github.com/git/git/commit/f4aa8c8bb11dae6e769cd930565173808cbb69c813:06
fungioh, right it was the older ensure_valid_ownership() check we dealt with in the past13:13
fungiwhere we cloned as one user but then accessed contents from that clone as another user13:14
fungiwhile this is cloning from a repo where the original is owned by a different user13:15
JayFWhat's the proper place to get support for bitergia? adamcarthur5 has updated all his information in openstack/opendev profile, including adding associated emails, but is still showing up as "Unknown" organization14:27
JayFI can fetch screenshots and all for proof and share privately if it's helpful14:28
JayFhe is also showing up as author name "Sharpz7" despite that only being the email/name he used for some commits; so I wonder if there's some kinda deduplication issue14:29
JayF(searching on Author_name: Sharpz7 shows his commits, unattributed to G-Research)14:29
clarkbJayF: what do you mean by an openstack/opendev profile? we don't really have opendev profiles so want to be clear on what got updated14:30
JayFthere's the one form on openstack.org which has some info, and some other info via the opendev provider is piped in14:31
JayFhttps://www.openstack.org/profile/ and https://id.openinfra.dev/accounts/user/profile14:31
JayFah, openinfra.dev not opendev14:32
JayFI guess this means I'm in the wrong venue :D 14:32
clarkback thanks, ya those would be the places I would expect updates to need to happen through. They are also run by the foundation as is the relationship with bitergia. We (fungi and myself) can pass along these questions though or I think you can reach out directly via support@someemail address or similar (I would need to dig that address up)14:32
JayFemail would be ideal, as I'm outta normal tz so async is wonderful14:33
clarkbI have to do a school run now but can figure that out after14:34
JayFif you wanna just email it to me at jay at gr-oss.io that'll be fine, no urgency at all14:34
JayFor here in a DM14:34
ildikovJayF: Hi, thank you for bringing up the Bitergia dashboard issue. As clarkb mentioned, we're still working on an official channel to report dashboard issues to us. In the meantime, to move this one along, can you please send me a summary of the issue in email (ildiko at openinfra dot dev)? Please feel free to attach screenshots, etc.15:23
ildikovJayF: if you haven't send the email yet, can you please send it to community@openinfra.dev rather? And if there are any other issues with the dashboard in the future, please use that email address to report it. Thank you!15:48
opendevreviewTony Breeds proposed opendev/system-config master: Add golang based docker compose tool.  https://review.opendev.org/c/opendev/system-config/+/92076015:49
opendevreviewTony Breeds proposed opendev/zone-opendev.org master: Remove old meetpad and jvb servers  https://review.opendev.org/c/opendev/zone-opendev.org/+/92076115:59
opendevreviewTony Breeds proposed opendev/system-config master: Remove old meetpad and jvb servers  https://review.opendev.org/c/opendev/system-config/+/92076216:01
opendevreviewClark Boylan proposed opendev/system-config master: Increase the number of mailman3 outgoing runners to 4  https://review.opendev.org/c/opendev/system-config/+/92076517:39
clarkbfungi: ^ fyi I didn't awnt to forget that we had discussed this briefly17:39
fungithanks! yes i meant to look into that17:39
opendevreviewAlbin Vass proposed zuul/zuul-jobs master: prepare-workspace-git: fix loop logic for older ansible versions  https://review.opendev.org/c/zuul/zuul-jobs/+/92076918:58
clarkbtonyb: I did leave a couple small comments on the docker compose change. Testing seemed to look good for that one though whcih is a great sign19:46
clarkbI need to run an errand so may be a bit before I can answer any questions related to thatthough19:47
tonybclarkb: all good.  I have research to do to answer your points anyway19:56
tonybActually going to finish early.  I have a local mediawiki working with OpenID (against LP) all the extensions load I haven't verified they work.20:09
tonybEven though I'm sticking with the same version as the current wiki I can't get the skin working which is a little strange but also no huge loss at this stage20:10
tonybI'm working on a rough pass at getting the inner (MW container) and outer (VM) apache configs to play ball and keep the same URLs20:11
tonybAll in all reasonably solid progress.20:11
fungisounds awesome, thanks for picking that up!20:12
tonybOh and I did do the linaro cert:20:38
tonybtony@thor:~$ openssl s_client -connect openinfraci.linaro.cloud:8004 < /dev/null |& grep -i before20:38
tonyb   v:NotBefore: May 29 19:24:40 2024 GMT; NotAfter: Aug 27 19:24:39 2024 GMT20:38
tonyb   v:NotBefore: Sep  4 00:00:00 2020 GMT; NotAfter: Sep 15 16:00:00 2025 GMT20:38
tonybtony@thor:~$ 20:38
fungithanks tonyb! i guess we should expect to not get a reminder about that later today/tonight20:42
clarkbok back21:00
clarkbthank you for rotating the cert21:01
clarkbthere is a lot of git permissions fallout on the zuul dashboard. I guess I was sort of ignoring that, but now am wondering if I need to look closer21:02
clarkbit looks liek it only complains in some cases? do we know why?21:02
clarkbcc corvus this may generally present a problem for prepare-workspace-git as well though I'm not sure yet: https://zuul.opendev.org/t/openstack/build/a10312d659ee4c2c85927f83224fff96/console21:03
corvusclarkb: thanks, i'm looking but i don't know any more than you yet21:07
corvus(in particular, i don't know what changed)21:08
clarkbcorvus: I think it only affect ubuntu nodes21:08
corvuscould it be related to a new image build?21:08
clarkbfrickler: metnioned early today there may be a ubuntu git package update causing it21:08
clarkbya21:08
clarkbdebian nodes seem fine fwiw and that seems to explain why some unittest jobs are ok and others are not (as they use different platforms to get access to different python versions)21:08
clarkbhttps://changelogs.ubuntu.com/changelogs/pool/main/g/git/git_2.34.1-1ubuntu1.11/changelog that seems to show related changelog entries21:09
corvusi'm assuming our cache in /opt/git is root-owned/world readable?  and if we want to keep it that way, we may need a fix to zuul-jobs; but if we don't, we could chown it zuul?  maybe?21:10
clarkbhttps://github.com/git/git/security/advisories/GHSA-xfc6-vwr8-r38921:10
clarkbcorvus: ya I think chowning to zuul will likely address it as long as the things breaking are running as zuul21:10
clarkbits possible that may break devstack like tools in separate ways (but thats probably ok)21:11
clarkb(probably ok since they are likely already broken too)21:11
corvusthis specific case is the global cache being used as an input to prepare-workspace-git; and i would expect devstack not to use that but instead use the results of prepare-workspace-git21:11
clarkbcorvus: looks like 755 root:root is what things are owned by in the git cache21:12
clarkbcorvus: oh ya good point21:12
clarkbso ya I think we can maybe chown to zuul:zuul and have that error go away21:13
clarkbalternatively set the safe directory flag in the images or as part of the jobs21:13
tonybI feel like setting the flag is okay for our use case 21:14
clarkbI think so considering the files are owned by root and you ahve to trust root.21:14
corvusyeah... part of me thinks that maybe a zuul-jobs fix would be good because it seems like this should be fine...but then if we did that would we be making assumptions about other systems that might not be true.  maybe we can trust it because it's owned by root, but maybe someone else set up a git repo cache owned by another user and it would be bad to blindly set the safe flag in zuul jobs21:17
tonybWe could set the flag in at image build time.21:19
tonybbut I do agree that not making assumptions is a good plan.21:21
clarkbI want to say we already did something similar to this somewhere too21:23
clarkbbut that may have been specific cases like devstack after lookingat codesarch21:23
clarkblooks like safe.directory can't be done recursively (but it may do globbing?) if we decide to modify our images then changing git cache ownership to zuul:zuul may be the best option there21:26
corvusi feel like there's a high probability that a fix in zuul-jobs would be universally okay, but we may not be able to guarantee it, so it may be better for opendev to fix this on images, and then for us to update the zuul-jobs docs for those roles to suggest other people do the same assuming their security posture is the same.21:26
corvus(or we could do an opt-in fix for zuul-jobs;  "evil-bit: false")21:26
jrosserI think you can list as many individual dirs as being safe as you like, or set “*”  to disable the check21:27
jrosserbut not /all/my/repos/*21:27
clarkbjrosser: ya thats a problem for us when we have like 2k things to list21:28
jrosserindeed I had to address this for osa this morning and settled on “*”21:28
clarkbside note: I feel like git clone should be somethign that can be done safely as the current userand create a new copy of a thing with appropriate permissions. But ya21:28
clarkbI can totally understand not making operating in someone elses repo safe. but cloning should be the safe firewall21:29
corvusyeah, this feels like the wrong solution in git.21:29
corvusokay, i think 2 viable solutions: 1) chown in images; 2) opt-in safe.directory additions in prepare-workspace-git21:31
clarkbI'm working on a project-config patch to chown the entire git cache recursively in dib image builds to zuul:zuul21:31
corvusok21:32
corvusi can delete the current ubuntu images so we use the fallbacks21:33
corvusis it just jammy? or all ubuntu?21:33
clarkbcorvus: so far I've only confirmed ajmmy is affected21:35
clarkbwe may end up immediately trying to rebuild the images once you delete them fwiw. Might also want to pause them21:35
opendevreviewClark Boylan proposed openstack/project-config master: Chown the /opt/git repo cache to zuul:zuul  https://review.opendev.org/c/openstack/project-config/+/92077921:38
clarkbsomething like that maybe. Not really tested  :/21:38
corvus#status log paused ubuntu-jammy builds and deleted all most-recent ubuntu-jammy images due to git package update21:39
opendevstatuscorvus: finished logging21:39
clarkbif 920779 looks good we can probably merge it then unpause jammy and have it rebuild with that change in place?21:40
clarkbslightly concerned this will end up creating some sort of unexpected failure elsewhere, but I'm not changing perms so should still be 755 meaning we're no worse than before in terms of access21:41
clarkblooks like focal was also updated: https://changelogs.ubuntu.com/changelogs/pool/main/g/git/git_2.25.1-1ubuntu3.12/changelog21:44
corvusanyone else want to review that, or should we +w it now?21:45
clarkbfungi and tonyb are probably the only other folks still around at this time of day?21:46
corvus#status log deleted the ubuntu-jammy-e57f97d15e0b4878afd4d262b4f8ba75 dib build21:47
opendevstatuscorvus: finished logging21:47
clarkbcorvus: I guess we go for it and worst case we pause and delete the new image again?21:50
clarkbthough I suppose my change will affect all image builds21:50
clarkbso the fallout could be much wider reaching than just ubuntu if there is a problem with chowning it for jobs (if the chwon itself fails then image buidls will fail)21:50
corvusimage build failure wouldn't be bad; failing everything would be worse, but we're already in a slow motion train wreck anyway21:55
corvusi think we should go for it21:55
clarkbya I'm leaning that direction too21:56
clarkbI feel like we're unlikely to make anything significantly worse21:56
clarkbanother option is to pause all image builds and then only unpause jammy once that is landed and see how it does21:57
clarkbto limit the blast radius. What do you think of that?21:57
corvusyeah, that may be the most conservative thing21:59
corvusi'll execute that22:00
clarkbcorvus: thanks, I was trying to determine if I could show which images are paused and which are not paused but seems that info isn't in dib-image-list?22:01
clarkboh wait it is there sorry22:01
corvus| ubuntu-jammy-e57f97d15e0b4878afd4d262b4f8ba75              | ubuntu-jammy              | nb02.opendev.org | qcow2,raw,vhd | paused   | 00:00:00:32  |22:01
clarkbI wanted to make sure that we didn't unpause any image builds later that should stay paused, but jammy is the only thing currently paused22:02
corvus#status log paused all image builds: https://paste.opendev.org/show/bxOJQAnEGwCHmeBs4tiU/22:02
opendevstatuscorvus: finished logging22:02
corvusthat has the list for easy unpausing later22:03
clarkbwe haven't built a new focal image yet since we only build it weekly22:03
clarkbits possibly noble is affected. Its newest image is 7 hours old. Unsure on that, but again its impact is limited at this point so I think we're mostly fine to focus on jammy, get that working then unpause the rest and rebuild noble22:04
corvus++22:04
tonybFWIW I +2d that change even though it's already got the +A22:04
corvusthanks!22:06
opendevreviewMerged openstack/project-config master: Chown the /opt/git repo cache to zuul:zuul  https://review.opendev.org/c/openstack/project-config/+/92077922:08
clarkbthat has enqueued the job we need to update the nodepool builders but it is behind the hourly jobs. Hopefully in 10-15 minutes we can unpause jammy and request a rebuild22:09
clarkbslightly worried I'm still going to be firefighting this stuff on Friady and will need to push gerrit upgrading back. But one thing at a time22:11
fungisorry, stepped out to dinner but looking at the git fixes now22:20
fungilooks like 920779 already merged22:21
clarkbyup and the deploy job for it is still running but it looks like nb01 and nb02 both have the new content on disk22:21
clarkbcorvus: I think we can unpause jammy and request a build nowish. Did you want tod o that or should I?22:22
clarkbfungi: assuming you think that plan is reasonable, saying something before we unpause and rebuild is a good idea :)22:23
fungifwiw, i would probably expect all images to end up impacted by this eventually, but with the chown in place that should be insurance against the distros/versions that haven't pushed backports yet22:23
clarkbfungi: yup  for sue22:23
fungiand yes, unpause and trigger a new build sgtm22:23
clarkb*for sure22:23
clarkbI'll go ahead and do it after the deploy job finishes if corvus doesn't say anything before then22:24
clarkband it just finished so I'm proceeding22:24
clarkbnb02 is building the image if anyone wants to follwo along with the logfile22:25
clarkbI may take a break here and then check back in an hour or two. Since we're just waiting otherwise22:28
corvussorry went afk; sounds good23:25
clarkbthe image build is nearing completion it is doing all the format conversions now23:41
fungiwhen i was waiting for the noble builds to finish, conversions took far longer than i expected23:52
clarkblooks like it took 10 minutes to go from raw to vhd intermediate. So hopefully no longer than 10 minutes to go from intermediate to final vhd23:54
clarkband then we haev to wait for uploads so probably at least another hour away from determining if this sufficiently satifisfies git's demands23:55

Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!