Wednesday, 2023-03-29

opendevreviewIan Wienand proposed zuul/zuul-jobs master: registry-tag-remove: role to delete tags from registry  https://review.opendev.org/c/zuul/zuul-jobs/+/87861400:32
opendevreviewIan Wienand proposed zuul/zuul-jobs master: promote-container-image: use generic tag removal role  https://review.opendev.org/c/zuul/zuul-jobs/+/87874000:32
opendevreviewwangxiyuan proposed openstack/diskimage-builder master: Rename openeuler mirror script  https://review.opendev.org/c/openstack/diskimage-builder/+/87880702:31
opendevreviewIan Wienand proposed zuul/zuul-jobs master: registry-tag-remove: role to delete tags from registry  https://review.opendev.org/c/zuul/zuul-jobs/+/87861404:05
opendevreviewIan Wienand proposed zuul/zuul-jobs master: promote-container-image: use generic tag removal role  https://review.opendev.org/c/zuul/zuul-jobs/+/87874004:05
opendevreviewIan Wienand proposed zuul/zuul-jobs master: registry-tag-remove: update docker age match  https://review.opendev.org/c/zuul/zuul-jobs/+/87881004:05
opendevreviewIan Wienand proposed zuul/zuul-jobs master: build-container-image: enhance buildx documentation  https://review.opendev.org/c/zuul/zuul-jobs/+/87849405:32
*** eandersson2 is now known as eandersson05:56
frickler#status log force-merged https://review.opendev.org/c/openstack/horizon/+/875326 to resolve deadlock caused by multi-branch failures06:06
opendevstatusfrickler: finished logging06:06
fricklerhttps://review.opendev.org/c/openstack/horizon/+/878751 is running jobs now, so that single force-merge seems indeed to have been enough06:06
*** amoralej|off is now known as amoralej07:26
opendevreviewMatthieu Huin proposed zuul/zuul-jobs master: upload-logs: Handle remote dir creation through rsync  https://review.opendev.org/c/zuul/zuul-jobs/+/87882910:16
mnasiadkaUbuntu arm64 mirror seems to be broken for some time - https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_03e/878649/3/check-arm64/kolla-build-ubuntu-aarch64/03ea09e/kolla/build/000_FAILED_base.log - anyone can help?10:28
frickler/afs/.openstack.org/mirror/ubuntu-ports/db/lockfile seems to be stale since Feb 2811:00
*** amoralej is now known as amoralej|lunch11:03
fricklerinfra-root: ^^ guess we can simply remove that file? unrelated: wheel releases also haven't happened for 7 days it seems, if someone wants to have a look11:04
fungifrickler: yeah, probably safe to remove, lsof doesn't show any processes with that open, nor is there any running reprepro process at the moment, so it's not hung just got left behind i guess (likely something killed the process). unfortunately it happened much longer ago than our reprepro log retention. i checked dmesg and nothing of consequence was logged around then11:43
*** amoralej|lunch is now known as amoralej12:19
fricklerrm: cannot remove '/afs/.openstack.org/mirror/ubuntu-ports/db/lockfile': Permission denied12:26
fricklerdo I need to do some kerberos stuff for that?12:26
fricklerguess yes, will wait until current reprepro run is done12:27
fricklerah, ports ran earlier. done with the rm. next cycle will be in 1.5h, will check logs after that12:30
frickler#status log removed stale lockfile dating Feb 28 /afs/.openstack.org/mirror/ubuntu-ports/db/lockfile12:31
opendevstatusfrickler: finished logging12:31
fungifrickler: yeah, presumably you found it already, but i added a "deleting a file" section in our afs docs which should cover that exact case13:23
fricklerI must admit that the docs are too complicated to navigate for me most of the time, I just looking into root history on mirror-update13:30
fricklermaybe I should at least bookmark some starting pages13:30
fungii agree the document could probably be far better organized to make things easier to find13:45
fungihttps://docs.opendev.org/opendev/system-config/latest/afs.html#deleting-files is the section i was referring tro13:46
fungis/tro/to/13:46
fricklerwhat would be the advantage of following those steps instead of simply using "k5start -t -f /etc/reprepro.keytab service/reprepro -- bash" as root@mirror-update ?14:57
fungimainly that i can do it from my workstation without needing to ssh into a server14:58
fricklerah, o.k., I never installed all that stuff locally15:00
fungii find it convenient since i can browse afs from my machine easily15:01
*** \join_iw19 is now known as \join_iwp915:26
*** amoralej is now known as amoralej|off16:49
opendevreviewSylvain Bauza proposed openstack/project-config master: Stop using Storyboard for Placement projects  https://review.opendev.org/c/openstack/project-config/+/87893217:53
clarkbinfra-root I continue to not understand how manage-projects was ever safe with multiple project renames merged in sequence. I've double checked projects.yaml's project listing and gerrit ls-projects and there are no additional projects implying we haven't accidentally recreated old projects after reanming them to a new name18:11
clarkbI thought maybe infra-prod-service-zuul was running and failing on the intermediate change with half old and half new names because the zuul reconfigure request would fail. But this job runs after manage-projects not before. It cannot fail and cause manage-projects to be skipped18:12
fungidid we determine that we're not using a zuul-merged checkout which incorporates all the changes which merged ahead of the change we're deploying?18:13
clarkbmanage-projects does depends on infra-prod-base, infra-prod-service-review, infra-prod-service-gitea, and system-config-promote-image-gerrit-3.6 when triggred by system-config. However, these changes are all in project-config and on the project config side manage-projects has no dependencies18:14
clarkbfungi: when corvus joiend the discussion the other day he made it seem like that wasn't the case. But I haven't managed to make a true test case for it18:14
clarkbbut ya  Ithink that remains the only good explanation I can come up with18:15
clarkbfungi: I think part of the concern with that even it works some of that time is that it ends up ebing a race18:15
fungioh, right, i keep forgetting that deploy uses the serial manager not the dependent manager, so can't just assume it uses the same kinds of merged refs18:16
clarkbfungi: because it depends on the timing between mergingin gerrit and when the zuul mergers merge the code for the job. If the zuul mergers execute that merge between when gerrit merges the two different changes you would be out of luck18:16
fungiand i guess serial doesn't incorporate changes ahead? or maybe that's what we haven't confirmed yet18:17
clarkbI think it would. The problem is the intermediate change not the last one to run18:18
clarkbif we have two different project rename changes A and B and force merge A first then B the git tree would end up looking liek A <- B. The problem is when the jobs run for A if the do not incorporate the changes from B then we would recreate an old project name18:19
clarkbwhen B runs it does include A and should be fine18:19
clarkbbut the more I dig into this the less I understand of how this ever worked without creating a bunch of orphaned projects18:20
fungido we maybe only run manage-projects for project entries that have changed rather than for all projects in the config?18:21
fungisince the projects which were deleted are already in the manage-projects cache they don't look like new projects to be created?18:23
clarkboh you know what18:24
clarkbI think that may be it18:24
clarkbI thought we always checked if the project was in gerrit and took action if not, but if we don't do that then this could be it18:25
clarkbheh we consult the cache for that info not gerrit ls-projects18:26
clarkbfungi: I think you solved it18:26
clarkbhttps://opendev.org/opendev/jeepyb/src/branch/master/jeepyb/cmd/manage_projects.py#L508-L52018:27
* fungi breathes a sigh of relief18:27
fungilet's make sure we don't invalidate that cache during a rename!18:28
clarkbya or just don't rely on it altogether. I'll need to think about this a bit18:28
clarkbmy initial impression is that we should thinkabout squashing the changes as the jeepyb cache could be cleared or not have the project in it for some reason (because its a cache!) and this is complicated enough it took me several hours of digging in and talking through it with others to track this down that being explicit seems better than implicit18:31
clarkbbut that does make things a bit weird for requesting renames from a user perspective. But we can do a last minute squash ourselves18:31
*** JayF is now known as Guest930819:44
*** JasonF is now known as jayf19:44
*** jayf is now known as JayF19:44
opendevreviewIan Wienand proposed zuul/zuul-jobs master: promote-image-container: do not delete tags  https://review.opendev.org/c/zuul/zuul-jobs/+/87861223:56
opendevreviewIan Wienand proposed zuul/zuul-jobs master: remove-registry-tag: role to delete tags from registry  https://review.opendev.org/c/zuul/zuul-jobs/+/87861423:56
opendevreviewIan Wienand proposed zuul/zuul-jobs master: promote-container-image: use generic tag removal role  https://review.opendev.org/c/zuul/zuul-jobs/+/87874023:56
opendevreviewIan Wienand proposed zuul/zuul-jobs master: remove-registry-tag: update docker age match  https://review.opendev.org/c/zuul/zuul-jobs/+/87881023:56
opendevreviewIan Wienand proposed zuul/zuul-jobs master: build-container-image: expand docs  https://review.opendev.org/c/zuul/zuul-jobs/+/87900823:56
opendevreviewIan Wienand proposed zuul/zuul-jobs master: container-build : add container_promote_method flag  https://review.opendev.org/c/zuul/zuul-jobs/+/87900923:56

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