| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 878039: Add implied-branch-matchers to tenant config https://review.opendev.org/c/zuul/zuul/+/878039 | 00:00 | |
| -@gerrit:opendev.org- Ian Wienand proposed: | 00:39 | |
| - [zuul/zuul] 878034: gerrit : filter unimplemented triggers https://review.opendev.org/c/zuul/zuul/+/878034 | ||
| - [zuul/zuul] 878041: gerrit trigger : alphabetize event lists https://review.opendev.org/c/zuul/zuul/+/878041 | ||
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: | 03:14 | |
| - [zuul/zuul-jobs] 878048: Revert "Use --password-stdin for upload-container-image" https://review.opendev.org/c/zuul/zuul-jobs/+/878048 | ||
| - [zuul/zuul-jobs] 878049: Add container repository cred permission checks https://review.opendev.org/c/zuul/zuul-jobs/+/878049 | ||
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed on behalf of Oleksandr Kozachenko: [zuul/zuul-jobs] 838919: Add promote-container-image role https://review.opendev.org/c/zuul/zuul-jobs/+/838919 | 03:14 | |
| -@gerrit:opendev.org- Ian Wienand proposed: [zuul/zuul] 878034: gerrit : filter unimplemented triggers https://review.opendev.org/c/zuul/zuul/+/878034 | 03:35 | |
| -@gerrit:opendev.org- Ian Wienand proposed: [zuul/nodepool] 871409: Update to DIB 3.27.0 https://review.opendev.org/c/zuul/nodepool/+/871409 | 03:42 | |
| -@gerrit:opendev.org- Zuul merged on behalf of Ian Wienand: [zuul/nodepool] 871409: Update to DIB 3.27.0 https://review.opendev.org/c/zuul/nodepool/+/871409 | 05:52 | |
| -@gerrit:opendev.org- Tobias Urdin proposed: [zuul/zuul] 877587: web: add dark mode and theme selection https://review.opendev.org/c/zuul/zuul/+/877587 | 08:50 | |
| @felixedel:matrix.org | Tobias Urdin corvus Regarding the dark-mode stack: I just saw that the changes are now squashed into a single one, which is fine for me. But maybe we could at least split the "PF4 upgrade changes" for some of the pages like projects, nodes, ... into a separate change to keep them independent of the dark mode? Maybe that is what you meant with: | 10:43 |
|---|---|---|
| > one, or maybe a small number (maybe 1 for the new ui selection elements, and 1 for the css fixes), seems like a good idea | ||
| @tobias-urdin:matrix.org | felixedel: sure, let me know any feedback you have and I'll move those three pages that change just the tables into separate changes in a final change, I'm guessing there might be more changes required so I'll bulk change all that together to save some time | 10:57 |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: | 14:56 | |
| - [zuul/zuul-jobs] 878048: Revert "Use --password-stdin for upload-container-image" https://review.opendev.org/c/zuul/zuul-jobs/+/878048 | ||
| - [zuul/zuul-jobs] 878049: Add container repository cred permission checks https://review.opendev.org/c/zuul/zuul-jobs/+/878049 | ||
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed on behalf of Oleksandr Kozachenko: [zuul/zuul-jobs] 838919: Add promote-container-image role https://review.opendev.org/c/zuul/zuul-jobs/+/838919 | 14:56 | |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul-jobs] 878137: Refactor docker/container image variables https://review.opendev.org/c/zuul/zuul-jobs/+/878137 | 17:00 | |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed on behalf of Oleksandr Kozachenko: [zuul/zuul-jobs] 838919: Add promote-container-image role https://review.opendev.org/c/zuul/zuul-jobs/+/838919 | 17:18 | |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: | 17:20 | |
| - [zuul/zuul-jobs] 878048: Revert "Use --password-stdin for upload-container-image" https://review.opendev.org/c/zuul/zuul-jobs/+/878048 | ||
| - [zuul/zuul-jobs] 878049: Add container repository cred permission checks https://review.opendev.org/c/zuul/zuul-jobs/+/878049 | ||
| - [zuul/zuul-jobs] 878137: Refactor docker/container image variables https://review.opendev.org/c/zuul/zuul-jobs/+/878137 | ||
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul-jobs] 878137: Refactor docker/container image variables https://review.opendev.org/c/zuul/zuul-jobs/+/878137 | 18:02 | |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul-jobs] 878172: Refactor docker/container image jobs https://review.opendev.org/c/zuul/zuul-jobs/+/878172 | 20:51 | |
| @clarkb:matrix.org | corvus: ianw left a comment on https://review.opendev.org/c/zuul/zuul/+/878034 but +2'd. I think that can be approved if my question doesn't result in an update | 20:57 |
| @iwienand:matrix.org | i have a couple of minor comments on the container/docker stack; one is i think the comment in https://review.opendev.org/c/zuul/zuul-jobs/+/838919 is inaccurate about it running on the executor and perhaps we can name the variables even better in https://review.opendev.org/c/zuul/zuul-jobs/+/878137. i'm happy to push some changes ontop if agrees | 22:11 |
| @iwienand:matrix.org | Clark: on the multiarch https://review.opendev.org/c/zuul/zuul-jobs/+/872806 is another one from the buildx path recently. in that massive bunch of ansible variables we were making unnecessary tags | 22:12 |
| @jim:acmegating.com | ianw: i think we have skopeo on the executor... lemme double check | 22:12 |
| @jim:acmegating.com | (if so, we can probably drop the docs mention about ensure-skopeo though -- so something is wrong either way :) | 22:13 |
| @jim:acmegating.com | yeah skopeo is installed | 22:14 |
| @iwienand:matrix.org | yeah COPY --from=skopeo-builder /tmp/skopeo /usr/local/bin/skopeo | 22:15 |
| @jim:acmegating.com | ianw: and agreed on point 2 | 22:16 |
| @iwienand:matrix.org | TIL (or perhaps TI-was-reminded-of-something-I-think-I-once-knew-but-had-fallen-out-of-my-head :) | 22:16 |
| @jim:acmegating.com | was a good thing to check -- certainly wasn't a sure thing. i'm glad though, i think it's important that the promote job runs fast | 22:17 |
| @jim:acmegating.com | we'll still need ensure-skopeo in the test jobs though since we won't have it in that environment | 22:17 |
| @jim:acmegating.com | ianw: i'm happy if you want to make those two changes in a followup | 22:18 |
| @iwienand:matrix.org | ok will do | 22:18 |
| @jim:acmegating.com | thanks :) | 22:19 |
| @iwienand:matrix.org | do people build their own executor environments, or do we expect them to use the container we create in the main Dockerfile? | 22:36 |
| @iwienand:matrix.org | (i'm just wondering if i say "skopeo is available in the executor" or "skopeo should be available in the executor") | 22:37 |
| -@gerrit:opendev.org- Ian Wienand proposed: | 22:58 | |
| - [zuul/zuul-jobs] 878175: containers : update test variable https://review.opendev.org/c/zuul/zuul-jobs/+/878175 | ||
| - [zuul/zuul-jobs] 878176: container role docs : clarify requirements https://review.opendev.org/c/zuul/zuul-jobs/+/878176 | ||
| @jim:acmegating.com | ianw: they do, so maybe the latter | 22:58 |
| -@gerrit:opendev.org- Ian Wienand proposed: [zuul/zuul-jobs] 878176: container role docs : clarify requirements https://review.opendev.org/c/zuul/zuul-jobs/+/878176 | 22:59 | |
| @jim:acmegating.com | we typically try to specify reqs like that in bindep.txt or requirements.txt in zuul-jobs; but sadly skopeo is an exception | 22:59 |
| @clarkb:matrix.org | ianw: I've approved https://review.opendev.org/c/zuul/zuul-jobs/+/872806 do you knowwhy we have to pull then push things? | 23:14 |
| @iwienand:matrix.org | i think it is to avoid having to have the intermediate registry | 23:16 |
| @clarkb:matrix.org | also https://danmanners.com/posts/2022-01-buildah-multi-arch/ is informative for multi arch | 23:16 |
| @clarkb:matrix.org | Unfortunately `docker build buildx` and `buildah` uses different flags and processes so I'll need to think about how we can make this a bit generic | 23:17 |
| @iwienand:matrix.org | so do we want to support multarch builds with both docker and podman in the build-container-image? | 23:18 |
| @clarkb:matrix.org | maybe we expect users to provide extra flags for the commands but then we can run them in a similar manner with that templated out | 23:18 |
| @clarkb:matrix.org | ianw: I think that is the ideal , but to start we probably only need `docker build buildx` for zuul and opendev purposes | 23:18 |
| @iwienand:matrix.org | are you thinking of calling buildah directly, or only via podman? | 23:20 |
| @clarkb:matrix.org | I'm not sure. I guess I didn't realize you can do it both ways. Probably stick to whichever method the roles currently defaultto? | 23:21 |
| @iwienand:matrix.org | well i think the role just calls podman build, which calls buildah underneath. i'm not sure though if it plumbs through enough to do multiarch builds | 23:22 |
| @clarkb:matrix.org | looks like `podman build` accepts the `--arch` and `--manifest` flags at least | 23:23 |
| @iwienand:matrix.org | just it does seem to make deciding what "container_command" is a bit more difficult | 23:23 |
| @iwienand:matrix.org | "what container command would you like to drive the totally different backend that actually builds this stuff" :) | 23:24 |
| @clarkb:matrix.org | ianw: I think we can continue with `podman` and maybe we add an image builds extra flags argument if it doesn't exist yet to pass in --arch and --manifest when multiarch is true | 23:24 |
| @clarkb:matrix.org | we can probably even default those values for docker and podman | 23:24 |
| @clarkb:matrix.org | ? | 23:25 |
| @clarkb:matrix.org | and then for both docker and podman do the separate builds then combine into a single manifest? I think the docker roles eseentially do this except they combine the builds into a single command | 23:25 |
| @clarkb:matrix.org | but then they push the manifest as a separate step so maybe we can be consistent there? Probably worth a shot I guess | 23:26 |
| @iwienand:matrix.org | yeah it does do both at once, becaues the output is all mixed up | 23:26 |
| @clarkb:matrix.org | may even be a nice improvement for debugging to split them up. I know I stuggle reading the interleaved logs | 23:27 |
| -@gerrit:opendev.org- Zuul merged on behalf of Ian Wienand: [zuul/zuul-jobs] 872806: build-docker-image: further cleanup buildx path https://review.opendev.org/c/zuul/zuul-jobs/+/872806 | 23:27 | |
| @clarkb:matrix.org | jobs may run longer but that is probably worthwhile in this instance | 23:27 |
| @iwienand:matrix.org | or faster due to less contention :) who knows | 23:31 |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul-jobs] 878172: Refactor docker/container image jobs https://review.opendev.org/c/zuul/zuul-jobs/+/878172 | 23:39 | |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul-jobs] 878172: Refactor docker/container image jobs https://review.opendev.org/c/zuul/zuul-jobs/+/878172 | 23:41 | |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul-jobs] 878172: Refactor docker/container image jobs https://review.opendev.org/c/zuul/zuul-jobs/+/878172 | 23:42 | |
| @clarkb:matrix.org | ianw: hrm I've just realized it is `docker buildx build` not `docker build buildx` which means we probably can't easily shim in an additional command name via extra args | 23:44 |
| @clarkb:matrix.org | part of me wonders if we don't need builder specific roles... Then we can include those from the docker roleset and the container roleset | 23:46 |
| @clarkb:matrix.org | if multiarch then include $container_command multiarch build role | 23:46 |
| @jim:acmegating.com | Clark: we can still just switch on the "container_command" for now, right? | 23:47 |
| @clarkb:matrix.org | everything else can be pretty generic and this way we can reuse the actual build role across the rolesets | 23:47 |
| @jim:acmegating.com | tbh, once this settles, i think we could make a convincing argument to deprecate and drop the *-docker-* roles. | 23:47 |
| @clarkb:matrix.org | corvus: yes, I'm basically coming to the conclusion that multiarch support is fairly tool specific. Whcih then led me to wondering about making specific roles and including those | 23:47 |
| @jim:acmegating.com | * tbh, once this settles, i think we could make a convincing argument to deprecate and drop the `*-docker-*` roles. | 23:47 |
| @clarkb:matrix.org | but ya I think ultimately we need to check the container command and then choose what to do. How we organize the actual code to be determined | 23:48 |
| @jim:acmegating.com | Clark: i think for now, i'd advocate for putting what i guess is now 3 options: (docker, docker buildx, podman) all in the container-bulid role (as individual included task lists that we switch on based on variables), copying from the docker-build role as appropriate, and then push for dropping the docker-build role. because if all we have left is container build roles, then i think that makes a lot of sense. if we decide to keep both, then it's probably a pretty tractable (and well-tested) refactor to split them out into a neutral third place. | 23:50 |
| @jim:acmegating.com | (and afaik, the only downside of the container roles compared to the docker roles is the auto-cleanup of leaked tags; that doesn't seem worth keeping both rolesets if it otherwise works well enough) | 23:51 |
| @clarkb:matrix.org | ya especially if we really only need to treat the build step as special and all the push/pull/tag/cleanup can be made consistent | 23:52 |
| @iwienand:matrix.org | this definitely makes sense as having two ways to use docker is a bit confusing, let alone the overhead of testing and maintaining it | 23:55 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!