-@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul-jobs] 878291: Add container build jobs https://review.opendev.org/c/zuul/zuul-jobs/+/878291 | 01:14 | |
-@gerrit:opendev.org- Ian Wienand proposed: [zuul/zuul-jobs] 878296: [dnm] test direct push https://review.opendev.org/c/zuul/zuul-jobs/+/878296 | 01:42 | |
-@gerrit:opendev.org- Ian Wienand proposed: [zuul/zuul-jobs] 878296: [dnm] test direct push https://review.opendev.org/c/zuul/zuul-jobs/+/878296 | 01:54 | |
-@gerrit:opendev.org- Ian Wienand proposed: [zuul/zuul-jobs] 878296: [dnm] test direct push https://review.opendev.org/c/zuul/zuul-jobs/+/878296 | 02:02 | |
-@gerrit:opendev.org- Ian Wienand proposed: [zuul/zuul-jobs] 878296: [dnm] test direct push https://review.opendev.org/c/zuul/zuul-jobs/+/878296 | 02:07 | |
-@gerrit:opendev.org- Ian Wienand proposed: [zuul/zuul-jobs] 878293: buildx: remove experimental flags https://review.opendev.org/c/zuul/zuul-jobs/+/878293 | 02:37 | |
@iwienand:matrix.org | "ERROR: failed to solve: missing provenance" | 02:49 |
---|---|---|
@iwienand:matrix.org | you know what i love : docker errors where there is exactly one other reference on the entire world-wide-web | 02:50 |
@iwienand:matrix.org | 02:55 | |
docker pull debian:testing Last pushed 13 minutes ago by doijanky | ||
@iwienand:matrix.org | i wonder if it's actually because this is so new | 02:55 |
-@gerrit:opendev.org- Ian Wienand proposed: | 03:07 | |
- [zuul/zuul-jobs] 878293: buildx: remove experimental flags https://review.opendev.org/c/zuul/zuul-jobs/+/878293 | ||
- [zuul/zuul-jobs] 878296: [dnm] test direct push https://review.opendev.org/c/zuul/zuul-jobs/+/878296 | ||
-@gerrit:opendev.org- Ian Wienand proposed: [zuul/zuul-jobs] 878296: [dnm] test direct push https://review.opendev.org/c/zuul/zuul-jobs/+/878296 | 03:26 | |
-@gerrit:opendev.org- Ian Wienand proposed: [zuul/zuul-jobs] 878296: [dnm] test direct push https://review.opendev.org/c/zuul/zuul-jobs/+/878296 | 03:32 | |
-@gerrit:opendev.org- Ian Wienand proposed: [zuul/zuul-jobs] 878296: [dnm] test direct push https://review.opendev.org/c/zuul/zuul-jobs/+/878296 | 03:40 | |
@iwienand:matrix.org | ok, just for the benefit of chatGPT and others discovering new ways to monetize all human knowledge | 03:52 |
@iwienand:matrix.org | the weird error "ERROR: failed to solve: missing provenance" from docker appears to be because i had accidentally specified the same architecture twice in the --platforms argument to docker buildx. i guess it pulls two versions of the same layer or something, and then gets confused between them? | 03:53 |
-@gerrit:opendev.org- Ian Wienand proposed: [zuul/zuul-jobs] 878296: [dnm] build-container-image : refactor buildx a bit https://review.opendev.org/c/zuul/zuul-jobs/+/878296 | 05:18 | |
-@gerrit:opendev.org- Ian Wienand proposed: [zuul/zuul-jobs] 878304: [dnm] testing manifest create https://review.opendev.org/c/zuul/zuul-jobs/+/878304 | 06:06 | |
-@gerrit:opendev.org- Ian Wienand proposed: [zuul/zuul-jobs] 878304: [dnm] testing manifest create https://review.opendev.org/c/zuul/zuul-jobs/+/878304 | 06:34 | |
@iwienand:matrix.org | i think it might be worth out time consolidating the buildx path to be the main/only docker build path in the container roles, not least because the "docker build" is showing a deprecation warning, so we're going to have to think about it some time | 06:37 |
@iwienand:matrix.org | i don't know if "docker manifest" existed when this was all written. probably not. but i think we can probably avoid starting up a temp registry if we use that | 06:37 |
@iwienand:matrix.org | and, it makes it look a lot like the buildah path too (create manifest, join arch images, push) | 06:37 |
@iwienand:matrix.org | anyway, i'm playing with it, but still mostly in my head | 06:38 |
-@gerrit:opendev.org- Ian Wienand proposed: [zuul/zuul-jobs] 878304: [dnm] testing manifest create https://review.opendev.org/c/zuul/zuul-jobs/+/878304 | 07:07 | |
-@gerrit:opendev.org- Dong Zhang proposed: [zuul/zuul] 876286: Add installation_id to event log https://review.opendev.org/c/zuul/zuul/+/876286 | 07:40 | |
-@gerrit:opendev.org- Simon Westphahl proposed: [zuul/zuul] 878313: Add missing event id to management events https://review.opendev.org/c/zuul/zuul/+/878313 | 07:49 | |
-@gerrit:opendev.org- Ian Wienand proposed: [zuul/zuul-jobs] 878304: [dnm] testing manifest create https://review.opendev.org/c/zuul/zuul-jobs/+/878304 | 07:50 | |
-@gerrit:opendev.org- Simon Westphahl proposed: [zuul/zuul] 878313: Add missing event id to management events https://review.opendev.org/c/zuul/zuul/+/878313 | 07:50 | |
-@gerrit:opendev.org- Ian Wienand proposed: [zuul/zuul-jobs] 878304: [dnm] testing manifest create https://review.opendev.org/c/zuul/zuul-jobs/+/878304 | 08:04 | |
-@gerrit:opendev.org- Simon Westphahl proposed: [zuul/zuul] 877245: Set cache ltime when branch protection changed https://review.opendev.org/c/zuul/zuul/+/877245 | 08:15 | |
-@gerrit:opendev.org- Ian Wienand proposed: [zuul/zuul-jobs] 878304: [dnm] testing manifest create https://review.opendev.org/c/zuul/zuul-jobs/+/878304 | 08:51 | |
-@gerrit:opendev.org- Zuul merged on behalf of Dong Zhang: [zuul/zuul] 876286: Add installation_id to event log https://review.opendev.org/c/zuul/zuul/+/876286 | 09:36 | |
-@gerrit:opendev.org- Simon Westphahl proposed: [zuul/zuul] 878313: Add missing event id to management events https://review.opendev.org/c/zuul/zuul/+/878313 | 09:50 | |
-@gerrit:opendev.org- Ian Wienand proposed: [zuul/zuul-jobs] 878304: [dnm] testing manifest create https://review.opendev.org/c/zuul/zuul-jobs/+/878304 | 09:56 | |
@iwienand:matrix.org | sigh, it seems like that was a waste of time | 10:12 |
@iwienand:matrix.org | https://zuul.opendev.org/t/zuul/build/c7f3b24e33274faea7cb7c10a3a3cbc8/console#2/0/88/builder | 10:12 |
@iwienand:matrix.org | docker manifest create requires the manifests to already be pushed | 10:13 |
@iwienand:matrix.org | the manifests you want to "join" together to make a multiarch manifest, i mean | 10:13 |
@iwienand:matrix.org | i'm guessing i'm now learning what the authors of this perhaps knew! | 10:13 |
-@gerrit:opendev.org- Ian Wienand proposed: [zuul/zuul-jobs] 878304: [dnm] testing manifest create https://review.opendev.org/c/zuul/zuul-jobs/+/878304 | 10:24 | |
-@gerrit:opendev.org- Ian Wienand proposed: [zuul/zuul-jobs] 878304: [dnm] testing manifest create https://review.opendev.org/c/zuul/zuul-jobs/+/878304 | 10:31 | |
@iwienand:matrix.org | Clark: basically i've been looking at the " # TODO is push here wrong?" bit. i don't think it's wrong, i do think we're tagging things unnecessarily and it's a bit confusing. after experimenting i'm still unsure how much less confusing we can make it | 10:37 |
-@gerrit:opendev.org- Ian Wienand proposed: [zuul/zuul-jobs] 878304: [dnm] testing manifest create https://review.opendev.org/c/zuul/zuul-jobs/+/878304 | 10:47 | |
@clarkb:matrix.org | ianw: sounds like you learned the old process is correct and we hsould just accept its convoluted and long :) | 15:18 |
@clarkb:matrix.org | corvus: for the zuul-ci quay org would it be helpful if I set up a tools team, a robot in that team, and some default permissions around the owners and tools teams? | 15:18 |
@clarkb:matrix.org | I did this for opendevorg and I think something along those lines is necessary bootstrapping for automation. It only takes a few minutes and I can do that if it hasn't been done yet | 15:19 |
@jim:acmegating.com | Clark: i thought i did that... | 15:26 |
@clarkb:matrix.org | oh maybe you did. I'm just sitting down for tea and local software updates | 15:27 |
@jim:acmegating.com | Clark: i think i mimicked what you did (thanks!) maybe you want to double check though? | 15:27 |
@clarkb:matrix.org | corvus: ah yup there is a team and a robot. I think you'll also want to add the default permissions though. These are so that when the robot or an owner creates a new repo everyone else in the org has appropriate permissions to start | 15:28 |
@jim:acmegating.com | oh ok, i was wondering if that was necessary because of the team settings... but now that i look at that, i'm guessing the "creator" team role means that the robot will be able to create a repo, and probably incidentally have write access to it because it created it (maybe). but won't automatically have permissions to any repos it doesn't create. | 15:30 |
@jim:acmegating.com | Clark: probably to do that, we would either need to set up the default perms as you suggest, or maybe we could give the automationtools team the admin role? | 15:31 |
@jim:acmegating.com | (if i'm right about that, we probably don't need an admin permission applied to owners default permission rule) | 15:32 |
@clarkb:matrix.org | > <@jim:acmegating.com> oh ok, i was wondering if that was necessary because of the team settings... but now that i look at that, i'm guessing the "creator" team role means that the robot will be able to create a repo, and probably incidentally have write access to it because it created it (maybe). but won't automatically have permissions to any repos it doesn't create. | 15:32 |
Not jus this but I think the owners don't implicitly get access either (they would have to go and take an owner step to add themselves after the fact) | ||
@clarkb:matrix.org | But that bit isn't super clear to me | 15:33 |
@jim:acmegating.com | oh, so that suggests the "admin" team role has distinct acls from the "admin" repo permission | 15:33 |
@clarkb:matrix.org | But importantly if we use the quay repo creation role as proposed the robot will have no permissiosn to push to the created repos by default | 15:33 |
@clarkb:matrix.org | so the default perms rules largely exist to ensure that the robot gets access to push after things are created without us needing to manually edit things | 15:33 |
@jim:acmegating.com | okay, i set up both default perms like opendev | 15:34 |
@jim:acmegating.com | Clark: i think there are 2 fronts right now: getting the multi-arch roles working, and getting the new jobs/publishing set up. on the jobs/publishing side, https://review.opendev.org/878291 is the first of a series of 3 changes and is ready to merge. adds the new jobs to zuul-jobs. | 15:50 |
@jim:acmegating.com | (next is add opendev versions of those jobs, then last is use the opendev jobs in a zuul repo) | 15:50 |
@jim:acmegating.com | if you have a minute to review/approve that, that would be great so we can keep this running in parallel. the opendev part is a config-project update, so these first 2 steps have to actually merge in order to proceed | 15:51 |
@clarkb:matrix.org | corvus: yup I'll take a look shortly | 16:07 |
@clarkb:matrix.org | corvus: for some reason I thought these jobs existed already? We only provided the roles previously? | 16:24 |
@jim:acmegating.com | Clark: you and me both | 16:25 |
@jim:acmegating.com | (btw, hashtag:container-jobs to see the other 2 changes in the stack) | 16:32 |
@clarkb:matrix.org | corvus: couple of talking out loud thoughts on that first change but lgtm | 16:44 |
-@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul-jobs] 878291: Add container build jobs https://review.opendev.org/c/zuul/zuul-jobs/+/878291 | 16:48 | |
@jim:acmegating.com | Clark: updated ^ | 16:48 |
@clarkb:matrix.org | corvus: similar talking out loud on the opendev/base-jobs change | 16:50 |
-@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 | 17:08 | |
-@gerrit:opendev.org- Zuul merged on behalf of James E. Blair https://matrix.to/#/@jim:acmegating.com: [zuul/zuul-jobs] 878291: Add container build jobs https://review.opendev.org/c/zuul/zuul-jobs/+/878291 | 17:09 | |
@clarkb:matrix.org | corvus: on the job feature parity update side of things have you had a chance to look at the changes to make multiarch pass testing? | 18:03 |
@jim:acmegating.com | Clark: where should i start? | 18:04 |
@jim:acmegating.com | https://review.opendev.org/878239 and child? | 18:04 |
@clarkb:matrix.org | https://review.opendev.org/c/zuul/zuul-jobs/+/878246 is the child yup | 18:04 |
@clarkb:matrix.org | I think that will get us support for buildkit in the simple case and multiarch with full buildx in the less simple case (eg for nodepool) | 18:05 |
@clarkb:matrix.org | or at least testing seems to indicate it is working | 18:05 |
@jim:acmegating.com | cool, i somehow didn't perceive that everything was ready for review; looking now. | 18:05 |
@clarkb:matrix.org | ya sorry I think the updates ianw made to it overnight got it into shape. It was really close when I called it a day yesterday | 18:05 |
@jim:acmegating.com | Clark: lgtm -- 2 nit-level comments | 18:09 |
@clarkb:matrix.org | good points I'll clean those up momentarily. The reason that docker bit is there is it carried over from the docker roles since we don't set the command there | 18:11 |
@jim:acmegating.com | i think next steps are: get all that merged; start exercising the build+publish pipeline with zuul-client; and in parallel exercise the multi-arch build (but not publish) with nodepool (using a DNM check-pipeline-only change) | 18:11 |
@jim:acmegating.com | > <@clarkb:matrix.org> good points I'll clean those up momentarily. The reason that docker bit is there is it carried over from the docker roles since we don't set the command there | 18:11 |
ah makes sense | ||
@clarkb:matrix.org | but we can definitely clean that up | 18:11 |
@jim:acmegating.com | i'll continue with the zuul-client stuff after lunch | 18:12 |
-@gerrit:opendev.org- Clark Boylan proposed on behalf of Ian Wienand: [zuul/zuul-jobs] 878293: buildx: remove experimental flags https://review.opendev.org/c/zuul/zuul-jobs/+/878293 | 18:14 | |
-@gerrit:opendev.org- Clark Boylan proposed: [zuul/zuul-jobs] 878246: Add docker buildx multiarch support to container roleset https://review.opendev.org/c/zuul/zuul-jobs/+/878246 | 18:14 | |
@clarkb:matrix.org | corvus: ^ comments addressed | 18:15 |
-@gerrit:opendev.org- Ian Wienand proposed: [zuul/zuul-jobs] 878304: [dnm] testing manifest create https://review.opendev.org/c/zuul/zuul-jobs/+/878304 | 19:25 | |
-@gerrit:opendev.org- Ian Wienand proposed: [zuul/zuul-jobs] 878304: [dnm] testing manifest create https://review.opendev.org/c/zuul/zuul-jobs/+/878304 | 19:45 | |
-@gerrit:opendev.org- Zuul merged on behalf of Clark Boylan: [zuul/zuul-jobs] 878239: Add support for passing env vars to the container build env https://review.opendev.org/c/zuul/zuul-jobs/+/878239 | 19:55 | |
-@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul-jobs] 878483: Fix container-image pre playbook container_command default https://review.opendev.org/c/zuul/zuul-jobs/+/878483 | 19:57 | |
-@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul-client] 878289: Publish images to quay.io https://review.opendev.org/c/zuul/zuul-client/+/878289 | 19:58 | |
@vlotorev:matrix.org | Hi, I can't quite understand what protects `infra-prod-*` jobs (opendev/system-config repo) from being enqueued into check pipeline. These jobs and their parents don't have `job.post-review=true` and `job.secrets`, opendev/system-config is untrusted. | 21:11 |
I mean that if I upload a change to system-config adding infra-prod to check pipeline the job won't run (my expectation), but what zuul rule protects from running these jobs there? | ||
infra-prod inherit from infra-prod-playbook, which inherits from opendev-infra-prod-base | ||
(links https://opendev.org/opendev/system-config/src/branch/master/zuul.d/infra-prod.yaml#L11, https://opendev.org/opendev/base-jobs/src/branch/master/zuul.d/jobs.yaml#L556) | ||
@vlotorev:matrix.org | * Hi, I can't quite understand what protects `infra-prod-*` jobs (opendev/system-config repo) from being enqueued into check pipeline. These jobs and their parents don't have `job.post-review=true` and `job.secrets`, opendev/system-config is untrusted. | 21:13 |
I mean, if I upload a change to system-config adding infra-prod to check pipeline the job won't run (my expectation), but what zuul rule protects from running these jobs there? | ||
infra-prod inherit from infra-prod-playbook, which inherits from opendev-infra-prod-base | ||
(links https://opendev.org/opendev/system-config/src/branch/master/zuul.d/infra-prod.yaml#L11, https://opendev.org/opendev/base-jobs/src/branch/master/zuul.d/jobs.yaml#L556) | ||
@iwienand:matrix.org | vlotorev: it's probably better to discuss this in #opendev, as it's not really zuul specific, but ... | 21:15 |
@iwienand:matrix.org | note the infra-prod jobs run in the "deploy" pipeline @ https://opendev.org/opendev/system-config/src/branch/master/zuul.d/project.yaml#L310 | 21:16 |
@clarkb:matrix.org | I think it has to do with access to the secrets more than anything else. | 21:17 |
@clarkb:matrix.org | secrets and the ssh keys are always post review | 21:18 |
@clarkb:matrix.org | the jobs rely on that | 21:18 |
@vlotorev:matrix.org | ianw: understand that, my question is 'what protection is used not to run infra-prod in check pipeline is someone uploads such a change'. | 21:19 |
@clarkb:matrix.org | so the jobs might run but not have access to do anything. We could explicitly mark them post review I suppose | 21:20 |
@clarkb:matrix.org | corvus: may have thoughts on that | 21:20 |
@jim:acmegating.com | i think the opendev jobs are fine the way they are | 21:23 |
@jim:acmegating.com | Clark: ianw https://zuul.opendev.org/t/zuul/build/9b5ace9593614c10adcc34a65b578017 zuul-client build is working now | 21:25 |
@clarkb:matrix.org | corvus: is that something you want ot see get approved to go through the entire upload nad promotion process? | 21:26 |
@clarkb:matrix.org | you'll need to manually make the image public afterwards (I noted that elsewhere) | 21:26 |
@jim:acmegating.com | yes, but i'm going to copy over the repo first | 21:26 |
@clarkb:matrix.org | ah ok tha talso works | 21:26 |
@clarkb:matrix.org | I'll review the chnage in that case | 21:27 |
@jim:acmegating.com | Clark: ianw i think that means we're ready to test the nodepool build -- if you like, i can propose a change for that since i have a handle on that part of it, and then turn it over to you for further debugging | 21:27 |
@clarkb:matrix.org | corvus: ++ | 21:27 |
-@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/nodepool] 878486: DNM: test multi-arch build https://review.opendev.org/c/zuul/nodepool/+/878486 | 21:35 | |
@iwienand:matrix.org | vlotorev: ahh, sorry, yes i misread what you wrote. i think the thing to note is that zuul logs into the bridge to run the production jobs, and the key it uses to do that is only available in the post-review pipeline (see https://zuul-ci.org/docs/zuul/latest/job-content.html#project-key). so if you run any of those jobs in a non-post-review pipeline, nothing can happen | 21:38 |
@iwienand:matrix.org | for your reference, the key is deployed via https://opendev.org/opendev/system-config/src/branch/master/inventory/base/group_vars/all.yaml#L156 | 21:40 |
@iwienand:matrix.org | also, the host is added "outside" system-config as well in the base jobs, at https://opendev.org/opendev/base-jobs/src/branch/master/playbooks/infra-prod/setup-keys.yaml | 21:40 |
@iwienand:matrix.org | * also, the bridge host is added "outside" system-config as well in the base jobs, at https://opendev.org/opendev/base-jobs/src/branch/master/playbooks/infra-prod/setup-keys.yaml | 21:41 |
@vlotorev:matrix.org | ianw: Thanks, got it. So the job will be run by zuul, but it will fail during playbook execution. | 21:41 |
@iwienand:matrix.org | right; the very first thing these jobs do is add the bastion host to the inventory and then run the production playbooks on the bastion host -> https://opendev.org/opendev/system-config/src/branch/master/playbooks/zuul/run-production-playbook.yaml | 21:45 |
@iwienand:matrix.org | so the executor can add the bastion host fine, but when it hits "- hosts: prod_bastion[0]" it's going to try to ssh to bridge, which it doesn't have the private key setup for. in the post pipeline, zuul will have already loaded that in with "ssh-add" | 21:46 |
@iwienand:matrix.org | vlotorev: i note you've read doc/source/open-infrastructure.rst :) if you feel like any bits of that could be clearer or explain bits like this better, please feel free to propose updates! | 21:59 |
@jim:acmegating.com | okay quay.io/zuul-ci/zuul-client has the content from dockerhub now (caution -- this is just provisional for testing) | 22:03 |
@jim:acmegating.com | so i'm going to approve that publication change job | 22:03 |
@iwienand:matrix.org | corvus: are we ok to go with https://review.opendev.org/c/zuul/zuul-jobs/+/878246/ to add the buildx path to continer-images? | 22:09 |
@jim:acmegating.com | ianw: yes i missed that my vote dropped, i'll +3 | 22:11 |
@jim:acmegating.com | cause https://review.opendev.org/878486 isn't much use without it :) | 22:11 |
-@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/nodepool] 878486: DNM: test multi-arch build https://review.opendev.org/c/zuul/nodepool/+/878486 | 22:12 | |
@jim:acmegating.com | that may not actually do anything because of trusted repos but hey | 22:12 |
@iwienand:matrix.org | i won't update 878293 but i did find https://docs.docker.com/engine/reference/commandline/cli/#experimental-features ```Starting with Docker 20.10, experimental CLI features are enabled by default, and require no configuration to enable them.``` ... so that explains it a bit better why we can drop the env vars | 22:16 |
-@gerrit:opendev.org- Zuul merged on behalf of Clark Boylan: [zuul/zuul-jobs] 878246: Add docker buildx multiarch support to container roleset https://review.opendev.org/c/zuul/zuul-jobs/+/878246 | 22:23 | |
-@gerrit:opendev.org- Zuul merged on behalf of Ian Wienand: [zuul/zuul-jobs] 878293: buildx: remove experimental flags https://review.opendev.org/c/zuul/zuul-jobs/+/878293 | 22:23 | |
-@gerrit:opendev.org- Ian Wienand proposed: [zuul/zuul-jobs] 878487: build-container-image: directly push with buildx https://review.opendev.org/c/zuul/zuul-jobs/+/878487 | 22:26 | |
@iwienand:matrix.org | mordred: Clark you each wrote one half of ^ so interested in your thoughts :) | 22:27 |
-@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul-jobs] 878488: Handle zk_image.repository not being defined in container roles https://review.opendev.org/c/zuul/zuul-jobs/+/878488 | 22:29 | |
@jim:acmegating.com | ianw: Clark ^ can you review 488 -- another prod oops | 22:30 |
@jim:acmegating.com | ianw: worth a shot | 22:30 |
@clarkb:matrix.org | corvus: yes left a couple of comments ( I think there is a typo) | 22:30 |
@clarkb:matrix.org | corvus: but also how is the repository optional? isn't that were we are promoting things? | 22:31 |
@jim:acmegating.com | Clark: this week has been *hard* to keep those straight :) | 22:31 |
@jim:acmegating.com | also, k and j are adjacent on my keyboard | 22:31 |
@clarkb:matrix.org | on mine as well but I suspect we use different keyboard layouts | 22:31 |
-@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul-jobs] 878488: Handle zk_image.repository not being defined in container roles https://review.opendev.org/c/zuul/zuul-jobs/+/878488 | 22:32 | |
@jim:acmegating.com | i can't remember the before days now | 22:32 |
@jim:acmegating.com | Clark: also you're right about the other thing, it's the *other* repository variable | 22:32 |
-@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul-jobs] 878488: Handle credential repository not being defined in container roles https://review.opendev.org/c/zuul/zuul-jobs/+/878488 | 22:34 | |
@jim:acmegating.com | Clark: ianw ^ there we go that's what i meant | 22:34 |
@clarkb:matrix.org | corvus: I'm still not sure I understand how that is optional? The next task after that one logs in using those same credentials? | 22:35 |
@jim:acmegating.com | Clark: the 'repository' part of the credential is optional lemme get a link | 22:36 |
@iwienand:matrix.org | that's the regex that restricts what updates right? | 22:36 |
@jim:acmegating.com | yep | 22:36 |
@jim:acmegating.com | https://zuul-ci.org/docs/zuul-jobs/container-roles.html#rolevar-build-container-image.container_registry_credentials.[registry%20name].repository | 22:36 |
@iwienand:matrix.org | although clear i should have read it closer | 22:36 |
@clarkb:matrix.org | oh I see we use the credentials later without hte .repository | 22:36 |
@clarkb:matrix.org | got it | 22:36 |
@jim:acmegating.com | that's the "let openstack use a single credential for the org and delegate access to repos via regex validation" feature. it's almost certainly never been used. | 22:38 |
@jim:acmegating.com | would be somewhat important for dockerhub. probably not necessary for quay. but hey, the works been (mostly) done. | 22:38 |
@iwienand:matrix.org | ... tangential, but how do you think "quay" is pronounced? | 22:39 |
@clarkb:matrix.org | I've been told its not like the keys of sydney but is a kway | 22:40 |
@jim:acmegating.com | ianw: i believe i'm the only person in north america that calls it "key dot eye oh". and then i say "oh lots of people call it 'kway' and then people say "ohhh". | 22:41 |
@clarkb:matrix.org | I find the word "quay" confusing in all cases :) | 22:41 |
@iwienand:matrix.org | haha it's not something i usually have to say out loud to anyone except for the past week :) i'm pretty sure most people don't understand me saying it like "key" | 22:42 |
@jim:acmegating.com | i think it's one of those words where every possible pronunciation is correct somewhere :) | 22:49 |
@clarkb:matrix.org | where I come from we called it a dock | 22:51 |
@clarkb:matrix.org | and for some reason it was never a pier. Maybe because a pier implies pilings rather than a solid construction? | 22:51 |
@clarkb:matrix.org | corvus: one thing missing from nodepool-build-image is artifacts listing the insecure ci registry download point. It also doesn't seem to have run with the new multiarch support having landed? | 23:23 |
@clarkb:matrix.org | ianw: ^ | 23:23 |
@clarkb:matrix.org | do we think simply rechecking is sufficient to rerun now that that change has landed? | 23:23 |
@clarkb:matrix.org | It does appear to have successfully built the x86_64 image though which is good | 23:24 |
@jim:acmegating.com | Clark: yeah, i think a recheck; i think the depends-on was a waste because of the config repo | 23:24 |
@clarkb:matrix.org | gotcha. rechecking now | 23:24 |
@clarkb:matrix.org | I suspect the artifacts thing is just something missing from the jobs themselves | 23:27 |
@iwienand:matrix.org | i think because it didn't push to intermediate registry | 23:27 |
@clarkb:matrix.org | oh it didn't? | 23:28 |
@iwienand:matrix.org | it skipped it - name: Push images to intermediate registry | 23:28 |
when: | ||
- docker_images is defined | ||
@iwienand:matrix.org | https://zuul.opendev.org/t/zuul/build/1fb913693538407a881141ea70ff7ef1/console#4/0/0/localhost | 23:28 |
@clarkb:matrix.org | aha we need that to say when docker images or container images is defined I think | 23:28 |
@clarkb:matrix.org | depending on where that check is | 23:28 |
@clarkb:matrix.org | if its specific to this set of roles then just container_images is fine | 23:28 |
@iwienand:matrix.org | that's in push-to-intermediate-registry in zuul-jobs | 23:29 |
@iwienand:matrix.org | want me to propose? | 23:29 |
@clarkb:matrix.org | yes I like that feature :) | 23:30 |
-@gerrit:opendev.org- Ian Wienand proposed: [zuul/zuul-jobs] 878492: push-to-intermediate-registry: look for container_images variable https://review.opendev.org/c/zuul/zuul-jobs/+/878492 | 23:33 | |
-@gerrit:opendev.org- Ian Wienand proposed: [zuul/zuul-jobs] 878492: push-to-intermediate-registry: look for container_images variable https://review.opendev.org/c/zuul/zuul-jobs/+/878492 | 23:35 | |
@iwienand:matrix.org | ^ that updates docs too; i guess we can clean that up when we deprecate the -docker- jobs? | 23:36 |
-@gerrit:opendev.org- Zuul merged on behalf of James E. Blair https://matrix.to/#/@jim:acmegating.com: [zuul/zuul-jobs] 878483: Fix container-image pre playbook container_command default https://review.opendev.org/c/zuul/zuul-jobs/+/878483 | 23:37 | |
@clarkb:matrix.org | ianw: hrm the tasks in the push.yaml appear to all rely on docker and assume it is installed which may not be the case for people using podman | 23:37 |
@clarkb:matrix.org | maybe we need a note that says you should also install docker if using this role alongside podman? | 23:37 |
@iwienand:matrix.org | oh hrm, i thought it was skopeoing | 23:37 |
-@gerrit:opendev.org- Zuul merged on behalf of James E. Blair https://matrix.to/#/@jim:acmegating.com: [zuul/zuul-jobs] 878488: Handle credential repository not being defined in container roles https://review.opendev.org/c/zuul/zuul-jobs/+/878488 | 23:38 | |
@clarkb:matrix.org | it creates a docker user config at least | 23:38 |
@iwienand:matrix.org | yeah, then it does skopeo --insecure-policy copy --all docker://127.0.0.1:{{ socat_port }}/ docker://{{ intermediate_registry.host | ipwrap }} | 23:40 |
@iwienand:matrix.org | where socat_port is a wrapper that points to the buildset registry | 23:40 |
@iwienand:matrix.org | it seems like it's using skopeo to go from buildset-registry -> intermediate, which suggests docker isn't involved? | 23:41 |
@clarkb:matrix.org | hrm what is all the stuff going on in https://review.opendev.org/c/zuul/zuul-jobs/+/878492/2/roles/push-to-intermediate-registry/tasks/push.yaml then? | 23:41 |
@iwienand:matrix.org | oh, yes i do agree that is all there :) | 23:42 |
@clarkb:matrix.org | does skopeo read the docker config maybe? | 23:42 |
@clarkb:matrix.org | I guess that could be and in that case this is all fine as we don't actually need docker installed? | 23:42 |
@iwienand:matrix.org | If6b1f3ab34461d77e619b188f48c5d209df7afce | 23:44 |
@iwienand:matrix.org | https://review.opendev.org/c/zuul/zuul-jobs/+/644241 | 23:44 |
@iwienand:matrix.org | it looks like yes, skopeo reads it for auth | 23:46 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!