| @clarkb:matrix.org | Looking at the skopeo docker api version thing again: https://github.com/docker/cli/blob/master/docs/deprecated.md#deprecate-legacy-api-versions is the documentation of the change on the docker side of things. Annoying that only an env var can be used to override this and not daemon config file entries | 17:33 |
|---|---|---|
| @clarkb:matrix.org | I think this is going to be somewhat problematic for anything using skopeo and talking to docker because skopeo doesn't seem to backport these fixes to old releases and current skopeo requires a fairly recent golang version to build. We might need to figure out how to build skopeo in a different environment then publish the resulting binary for older platforms? | 17:34 |
| @clarkb:matrix.org | I was thinking I would just set that env var for now but since the next major release of docker will remove it I'm not sure it is worth the trouble | 17:35 |
| @clarkb:matrix.org | side note: `Use of old API versions is very rare` seems to be incorrect given the popularity of skopeo using an old version | 17:35 |
| @clarkb:matrix.org | on second glance at the skopeo code base tehy do have stable release branches. Maybe we can convince them to backport the fix? Anyone know anyone over there we can talk to about that? | 17:36 |
| @clarkb:matrix.org | Looks like it is actually the image library that skopeo consumes that needs the fix backported then old branches of skopeo need to pull in the backport fixed image releases | 17:39 |
| @clarkb:matrix.org | From an end user usablity standpoint I suspect that this will be very helpful to get done | 17:39 |
| @mordred:waterwanders.com | Clark: multi-stage build docker image for skopeo build? Use a super-new golang base image to build it, then copy the binary from that build stage to the target stage on the version you want? | 18:17 |
| @mordred:waterwanders.com | (in case you want/need new skopeo on old platform) | 18:17 |
| @clarkb:matrix.org | mordred: no skopeo cannot push to an up to date dockerd right now | 18:17 |
| @mordred:waterwanders.com | even new skopeo? wow | 18:17 |
| @clarkb:matrix.org | mordred: the reason for this is skopeo hardcoded an ancient version of the docker api into its api handlings | 18:18 |
| @mordred:waterwanders.com | "neat" | 18:18 |
| @clarkb:matrix.org | an unreleased version of skopeo fixes this by negotiating the api version, but that only helps if you can install latest skopeo which is difficult on platforms like Jammy which have golang that is too old to build latest skopeo | 18:18 |
| @clarkb:matrix.org | https://github.com/containers/skopeo/issues/2202#issuecomment-1908830671 has more details | 18:19 |
| @mordred:waterwanders.com | oh right - no, that's what I was saying - use newer platform to build, then just copy the binary. It's simple in multi-stage image build ... _slightly_ harder if you're looking for a non-docker source of the skopeo binary - but even then you could use docker to do the build and then just export the binary | 18:19 |
| @mordred:waterwanders.com | you know BASE sid as build-layer ; build skopeo ; BASE jammy ; COPY FROM build-layer /opt/skopeo/bin/sillypath/skopeo ... or whatever the actual syntax is :) | 18:20 |
| @clarkb:matrix.org | oh I see what you are saying. Yes could build in a container then copy it either to another container or to the host | 18:20 |
| @mordred:waterwanders.com | I'm not the world's biggest golang fan - but the combo of multi-stage builds and static binaries does solves a few issues occasionally | 18:21 |
| -@gerrit:opendev.org- Tristan Cacqueray https://matrix.to/#/@tristanc_:matrix.org proposed: [zuul/zuul] 908197: web: bump re-ansi to support bright color https://review.opendev.org/c/zuul/zuul/+/908197 | 20:15 | |
| @tristanc_:matrix.org | It appears that we are running 256+ jobs every week to check zuul-jobs (https://lists.zuul-ci.org/archives/list/zuul-jobs-failures@lists.zuul-ci.org/), is this useful? | 21:46 |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 908202: Use exec in tutorial docker-compose files https://review.opendev.org/c/zuul/zuul/+/908202 | 21:50 | |
| @jim:acmegating.com | i don't know what changed to cause the quick-start job to fail (and i checked podman versions, etc). maybe something just ended up getting sorted differently. or maybe dumb-init changed (i didn't check that). anyway, ^ that should fix it | 21:51 |
| @jim:acmegating.com | tristanC: i think they have proven useful in the past. it would be nice if the base roles jobs were updated to be compatible with that pipeline; that would be even more useful. at any rate, opendev hasn't asked us to stop. :) | 21:52 |
| @jim:acmegating.com | (since we don't run all jobs on every change, and many roles go ages without being touched, it can be nice to have some history when someone finds that something has broken) | 21:53 |
| -@gerrit:opendev.org- Tristan Cacqueray https://matrix.to/#/@tristanc_:matrix.org proposed: [zuul/zuul-jobs] 827369: Remove the periodic-weekly pipeline https://review.opendev.org/c/zuul/zuul-jobs/+/827369 | 21:53 | |
| @tristanc_:matrix.org | It seems like ssbarnea added the periodic pipeline, but it does not seems like it is being used anymore. | 21:57 |
| @jim:acmegating.com | i referred to it yesterday (though it didn't have the answer i was looking for) | 21:58 |
| @jim:acmegating.com | i'm not sure how we'd determine that it wasn't being used | 21:58 |
| @jim:acmegating.com | if you mean, is anyone watching the emails and acting to correct failures? i agree, it doesn't look like it. but that's not the only use. | 21:58 |
| @tristanc_:matrix.org | yes, I wondered what's the purpose when the notification appears to always indicate a failure. | 22:04 |
| @jim:acmegating.com | i have no opinions on the email notification. we could remove it from the pipeline definition if we want, though also if no one subscribes to the list then it's not really a problem. fwiw, i don't subscribe to the list. | 22:05 |
| @jim:acmegating.com | there's definitely an opportunity for folks to help with general maintenance in zuul-jobs. | 22:07 |
| @clarkb:matrix.org | fungi: may have an opinion as I think openstacks periodic job reports were the biggest mailing list archive that had to be migrated to mm3. But even then it worked fine | 22:08 |
| @jim:acmegating.com | i guess, in case it's not clear, the way i use it is through the build history in zuul | 22:08 |
| -@gerrit:opendev.org- Tristan Cacqueray https://matrix.to/#/@tristanc_:matrix.org proposed: [zuul/project-config] 908204: Disable zuul-jobs-failures@lists.zuul-ci.org weekly failure https://review.opendev.org/c/zuul/project-config/+/908204 | 22:11 | |
| @fungicide:matrix.org | yeah, zuul's case is way different from openstack's. the periodic buildset failure reports are per-project+branch combination, and zuul just doesn't have many projects compared to openstack nor does it branch them | 22:11 |
| @fungicide:matrix.org | openstack was, at its worst, generating approximately 150 failure e-mails per day for periodic buildsets | 22:11 |
| @fungicide:matrix.org | that's not 150 failing builds, but unique project+branch buildsets with one or more failures each | 22:12 |
| @fungicide:matrix.org | now it's down around a dozen each day, which is a pretty amazing feat in itself, but still way more than zuul's projects generate | 22:13 |
| @fungicide:matrix.org | especially since for zuul we're not even talking about daily, but rather weekly jobs | 22:14 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!