Monday, 2023-02-06

-@gerrit:opendev.org- Simon Westphahl proposed:07:07
- [zuul/zuul] 869361: Add scheduler run handler metric https://review.opendev.org/c/zuul/zuul/+/869361
- [zuul/zuul] 869362: Add more log messages for run handler steps https://review.opendev.org/c/zuul/zuul/+/869362
@elpell:matrix.org> <@clarkb:matrix.org> Per Wiklund: out of curiousity what was it?07:25
The problem was a merge conflict between changes A and B, and B was already merged. However, zuul only reports this "Failed to enqueue changes ahead of A" when looking up the event id in the scheduler logs. So here I could guess that a rebase should solve the problem. But the patchset was never dequeued from zuul, only when the rebased patchset was uploaded (as expected) so as a follow-up question how does zuul handle merge conflicts and when does it feedback a merge conflict to gerrit?
-@gerrit:opendev.org- Ian Wienand proposed: [zuul/zuul-jobs] 872733: ensure-skopeo: fixup some typos https://review.opendev.org/c/zuul/zuul-jobs/+/87273308:44
@iwienand:matrix.orgcorvus: if you have a sec to review the skopeo install from source in https://review.opendev.org/c/zuul/zuul-jobs/+/872365 that would be good, and should unblock the largish stack to get us new ansible-lint and update all the container jobs to jammy08:47
-@gerrit:opendev.org- Zuul merged on behalf of Ian Wienand: [zuul/zuul-jobs] 872617: ensure-skopeo: add install from upstream option https://review.opendev.org/c/zuul/zuul-jobs/+/87261708:57
-@gerrit:opendev.org- Zuul merged on behalf of Ian Wienand: [zuul/zuul-jobs] 872365: zuul-jobs-test-registry-docker-* : update to jammy nodes https://review.opendev.org/c/zuul/zuul-jobs/+/87236509:56
-@gerrit:opendev.org- Ade Lee proposed: [zuul/zuul-jobs] 866881: Add ubuntu to enable-fips role https://review.opendev.org/c/zuul/zuul-jobs/+/86688110:55
@clarkb:matrix.orgIf any zuulians have time for https://review.opendev.org/c/zuul/zuul/+/872034 and https://review.opendev.org/c/zuul/zuul/+/872363 these are two relatively safe (due to testing) changes that prepare us for sqlalchemy 2.0. THen when we are ready to take the plunge the child change swaps us over to sqlalchemy 2.017:00
@jim:acmegating.comalso feedback on https://review.opendev.org/872226 (mysql vs mariadb) is very welcome17:16
@jim:acmegating.com * also related: feedback on https://review.opendev.org/872226 (mysql vs mariadb) is very welcome17:16
@clarkb:matrix.orgI'm starting to look at the ResourceWarnings that are emitted by the zuul test suite too. The tooling around this is actually pretty neat. What I don't understand is why PYTHONDEVMODE is seemingly enabled though17:20
-@gerrit:opendev.org- Clark Boylan proposed: [zuul/zuul] 872799: Cleanup some Python ResourceWarnings in the test suite https://review.opendev.org/c/zuul/zuul/+/87279917:44
@clarkb:matrix.orgwith ^ sorted out and my kazoo PR merged we should be in good shape for reducing noise in the test suite (it bugged me during the sqlalchemy 2.0 work)17:48
@clarkb:matrix.orgI'll have to see if the test runs for that change catch anymore ResourceWarnings and try to sort them out too17:49
@clarkb:matrix.orgoh I bet we have a similar bug with fake gerrit in fake github, but I'll let the test runs confirm17:49
-@gerrit:opendev.org- Clark Boylan proposed: [zuul/zuul] 872799: Cleanup some Python ResourceWarnings in the test suite https://review.opendev.org/c/zuul/zuul/+/87279918:33
-@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/nodepool] 872722: Add scheduler, volumes, and labels to k8s/openshift https://review.opendev.org/c/zuul/nodepool/+/87272220:07
-@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 872482: Fix race condition in pipeline change list init https://review.opendev.org/c/zuul/zuul/+/87248220:55
-@gerrit:opendev.org- Zuul merged on behalf of Ian Wienand:21:36
- [zuul/zuul-jobs] 872490: ansible-lint: fix a bunch of command-instead-of-shell errors https://review.opendev.org/c/zuul/zuul-jobs/+/872490
- [zuul/zuul-jobs] 872491: ansible-lint: add names to blocks/includes, etc. https://review.opendev.org/c/zuul/zuul-jobs/+/872491
-@gerrit:opendev.org- Zuul merged on behalf of Ian Wienand: [zuul/zuul-jobs] 872492: ansible-lint: ignore use of mkdir https://review.opendev.org/c/zuul/zuul-jobs/+/87249221:36
@iwienand:matrix.orgzuul-maint: if i could get one more +2 on https://review.opendev.org/c/zuul/zuul-jobs/+/872493/6 which is just a ansible-lint update to add some pipefail's, that would be great to unblock the stack21:44
@jim:acmegating.comianw: done22:12
@jim:acmegating.comianw: Clark looking at https://review.opendev.org/872258 -- i'm following the path to the change which caused the underlying problem.  that change was incorrect and should not have been merged in the first place.  it's counter to the design to use an upload followed immediately by a promote job.  periodic pipelines should only directly upload images (just like tag-based pipelines do -- we just run "upload-docker-image" in the release pipeline.  how can we go about fixing that?22:16
@iwienand:matrix.orgwe are looking at https://review.opendev.org/c/zuul/zuul-jobs/+/740560 right?22:20
@jim:acmegating.comyep22:20
@jim:acmegating.comianw: oh, are they trying to two-phase commit tow different image builds?22:21
@jim:acmegating.com * ianw: oh, are they trying to two-phase commit two different image builds?22:22
@jim:acmegating.comi think that must be it.  that does make sense and is a creative use.  that could have used more docs, but at least i think we can reverse-engineer the idea from the example in the commit msg.  if i'm following correctly now, then i don't think we need to revisit that.22:24
@jim:acmegating.com(the *text* of the commit message says "upload and promote images using periodic jobs".  the *yaml* in the commit message says "upload and promote two images each of which must only be updated if the other is good")22:25
@jim:acmegating.comhaving said that -- it's not clear to me that use case survived the change to the temp registry; i think that may have broken that22:30
@jim:acmegating.com(i'm seeing buildx.yaml push to docker_registry with `change_` hardcoded later in the file.  that's the equivalent action to what was altered in 74056022:31
@jim:acmegating.comso it's possible the tag_prefix is more or less dead code now)22:31
@iwienand:matrix.orgi think that basically all of that bit in the buildx path is unnecessary22:32
@iwienand:matrix.orgit makes all these tags in the temporary registry which is not used 22:32
@jim:acmegating.comianw: which gets to my next thought -- that i think your change is safe because nothing uses that now, yeah.  exactly what you just said :)22:32
@iwienand:matrix.orgi can clean it up further.  i think i just wanted to double-check that the tags didn't get pulled somehow back from the temp registry, and then i remember that 22:33
@jim:acmegating.comhttps://opendev.org/zuul/zuul-jobs/src/branch/master/roles/build-docker-image/tasks/buildx.yaml#L71-L88 are the "important" tags, right?22:34
@iwienand:matrix.org * i can clean it up further.  i think i just wanted to double-check that the tags didn't get pulled somehow back from the temp registry22:34
@jim:acmegating.com> <@iwienand:matrix.org> i can clean it up further.  i think i just wanted to double-check that the tags didn't get pulled somehow back from the temp registry22:34
yeah, i think i agree with that.
-@gerrit:opendev.org- Zuul merged on behalf of Ian Wienand:22:35
- [zuul/zuul-jobs] 872493: ansible-lint: use pipefail https://review.opendev.org/c/zuul/zuul-jobs/+/872493
- [zuul/zuul-jobs] 872494: ansible-lint: ignore latest git pull https://review.opendev.org/c/zuul/zuul-jobs/+/872494
@iwienand:matrix.orgi guess all we pull from the temp registry is ```docker pull {{ temp_registry.host }}:{{ temp_registry.port }}/{{ zj_image.repository }}:{{ zj_image_tag }}```22:35
@jim:acmegating.comyeah i think that's the only one we need22:35
@jim:acmegating.com+2 with comments22:35
@jim:acmegating.comtoo bad 740560 didn't add a test of that use case :(22:37
@iwienand:matrix.orgi only started looking at this because i was debugging and noticed the change_change_ prefix in the logs, and was thinking "that doesn't seem right".  but nothing was actually failing22:36
@iwienand:matrix.orgi'm trying to see if i had any other context in my notes22:38
@iwienand:matrix.org> <@jim:acmegating.com> ianw: Clark looking at https://review.opendev.org/872258 -- i'm following the path to the change which caused the underlying problem.  that change was incorrect and should not have been merged in the first place.  it's counter to the design to use an upload followed immediately by a promote job.  periodic pipelines should only directly upload images (just like tag-based pipelines do -- we just run "upload-docker-image" in the release pipeline.  how can we go about fixing that?22:45
this doesn't result in an extra upload though, right? it's just pushing the manifest for the uploaded image in the promote step with different tags?
-@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/nodepool] 872722: Add scheduler, volumes, and labels to k8s/openshift https://review.opendev.org/c/zuul/nodepool/+/87272222:46
@jim:acmegating.comianw: correct.  my point was that there's no reason to push to dockerhub and then retag on dockerhub (upload + promote) when you can just push to dockerhub with the final tag (promote as we use it in the release pipeline).  but that was before i sussed out that the bit about there being two images.22:48
-@gerrit:opendev.org- Ian Wienand proposed: [zuul/zuul-jobs] 872806: build-docker-image: further cleanup buildx path https://review.opendev.org/c/zuul/zuul-jobs/+/87280622:58
@iwienand:matrix.orgcorvus: ^ i think that is where i got to with that22:59
@jim:acmegating.comianw: lgtm thanks!  hopefully that will reduce our cognitive load :)23:00
@iwienand:matrix.org> <@jim:acmegating.com> (the *text* of the commit message says "upload and promote images using periodic jobs".  the *yaml* in the commit message says "upload and promote two images each of which must only be updated if the other is good")23:05
right -- the example does use the buildset registry for testing, and then uploads the images after that. but if it also promoted there, if one image failed to upload, the other would be uploaded and tagged. so by having the promote step depend on both uploads, you're ensuring that doesn't happen
@iwienand:matrix.org(pretty sure we're in agreement on what's happening,  just checking :)23:05
@jim:acmegating.comyep23:05

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