@jjbeckman:matrix.org | > <@clarkb:matrix.org> You may need to use namespaces instead of pods so that the job(s) can manage registry secrets and set that metadata on the image pull spec | 02:48 |
---|---|---|
If anyone could point me to how one could use an image registry other than docker.io, it would be greatly appreciated. Still haven't been able to figure how to do so with Nexus. | ||
@iwienand:matrix.org | > <@gerrit:opendev.org> Clark Boylan proposed: [zuul/zuul-jobs] 881277: Use full image url in container buildx path https://review.opendev.org/c/zuul/zuul-jobs/+/881277 | 04:45 |
I've dropped some comments but I feel like this is the wrong name ... if the buildset registry has a tag ```quay.io/foo/bar:latest```, any pulls like "docker pull quay.io/foo/bar:latest" in jobs later on are going to split that up into "ask quay.io for /foo/bar:latest", where after using ```use-buildset-registry```, "ask quay.io" equates to "ask the buildset registry for", since we set the buildset registry up as a mirror. i.e. the buildset registry is going to get asks for ```foo/bar:latest``` which it won't see, because it only has ```quay.io/foo/bar:latest```? | ||
@iwienand:matrix.org | > <@gerrit:opendev.org> Clark Boylan proposed: [zuul/zuul-jobs] 881277: Use full image url in container buildx path https://review.opendev.org/c/zuul/zuul-jobs/+/881277 | 04:45 |
* I've dropped some comments but I feel like this is the wrong name ... if the buildset registry has a tag `quay.io/foo/bar:latest`, any pulls like "docker pull quay.io/foo/bar:latest" in jobs later on are going to split that up into "ask quay.io for foo/bar:latest", where after using `use-buildset-registry`, "ask quay.io" equates to "ask the buildset registry for", since we set the buildset registry up as a mirror. i.e. the buildset registry is going to get asks for `foo/bar:latest` which it won't see, because it only has `quay.io/foo/bar:latest`? | ||
@iwienand:matrix.org | * I've dropped some comments but I feel like this is the wrong name ... if the buildset registry has a tag `quay.io/foo/bar:latest`, any pulls like "docker pull quay.io/foo/bar:latest" in jobs later on are going to split that up into "ask quay.io for foo/bar:latest", where after using `use-buildset-registry`, "ask quay.io" equates to "ask the buildset registry for", since we set the buildset registry up as a mirror. i.e. the buildset registry is going to get asked for `foo/bar:latest` which it won't see, because it only has `quay.io/foo/bar:latest`? | 04:46 |
@clarkb:matrix.org | ianw: the reason for the prefix is that we may have different colliding images for different registries | 04:51 |
@clarkb:matrix.org | It hasn't really been an issue until now but I think the intention was always to support that? | 04:51 |
@clarkb:matrix.org | > <@jjbeckman:matrix.org> If anyone could point me to how one could use an image registry other than docker.io, it would be greatly appreciated. Still haven't been able to figure how to do so with Nexus. | 04:52 |
Have you tried using namespace resources instead? Then you should be able to create image resources in the job that set credentials for the registry. | ||
@iwienand:matrix.org | > <@clarkb:matrix.org> ianw: the reason for the prefix is that we may have different colliding images for different registries | 05:13 |
Yeah, I agree, but I'm not 100% that we are setup so that with a buildset registry, ```docker pull quay.io/foo/bar``` actually asks for ```buildset-registry:5000/quay.io/foo/bar```? | ||
@iwienand:matrix.org | https://opendev.org/zuul/zuul-jobs/src/commit/b7f983c6210bf6d57a343c67d6b87168a305c3e4/roles/use-buildset-registry/library/modify_registries_conf.py#L63 | 05:13 |
@clarkb:matrix.org | It looks like that does add the buildset registry with the prefix as the first location to check them the actual location (via raw prefix) otherwise | 05:23 |
@iwienand:matrix.org | yeah, ok, i may have confused myself by looking too hard at it | 05:58 |
@jjbeckman:matrix.org | > <@clarkb:matrix.org> Have you tried using namespace resources instead? Then you should be able to create image resources in the job that set credentials for the registry. | 06:38 |
Thank you for the suggestion. No, I have not tried namespaces yet. I've configured `type: namespace` in `nodepool.yaml`, and have observed that Zuul creates namespaces which contain no pods. Other than that, I have yet to figure out what the intended use case is. Does documentation regarding how to use "type: namespace" instead of `type: pod`, which I am able to use successfully, other than the fact that there is seemingly no way to authenticate with a private registry. | ||
@clarkb:matrix.org | > <@jjbeckman:matrix.org> Thank you for the suggestion. No, I have not tried namespaces yet. I've configured `type: namespace` in `nodepool.yaml`, and have observed that Zuul creates namespaces which contain no pods. Other than that, I have yet to figure out what the intended use case is. Does documentation regarding how to use "type: namespace" instead of `type: pod`, which I am able to use successfully, other than the fact that there is seemingly no way to authenticate with a private registry. | 15:40 |
When you use the namespace resources instead of pod resources you are given credentials for managing a k8s namespace. This means you can create pods in that namespace how you like. I believe this includes creating image definitions with credetnials to authenticate to your registry. As I mentioned before I don't think there is any mechanism currently to have the pod resource provider configure registry authentication. But I suspect that you can work around this using namespaces | ||
@clarkb:matrix.org | corvus: I think https://review.opendev.org/c/zuul/zuul-jobs/+/881277 is the next step for nodepool image builds + quay. Please look it over carefully though as the switch to localhost in testing sort of papers over a limitation here. But one that has always existed I believe, just more apparent now without the docker default registry being used | 15:41 |
@jim:acmegating.com | Clark: +2 with comment on that | 20:39 |
@clarkb:matrix.org | corvus: cool I think we can probably approve that now as a workaround and figure out making this better once the quay transition is done? | 20:45 |
@jim:acmegating.com | Clark: wfm | 20:46 |
@clarkb:matrix.org | should I approve it or do you want to do that? | 20:48 |
@jim:acmegating.com | done | 20:49 |
-@gerrit:opendev.org- Zuul merged on behalf of Clark Boylan: [zuul/zuul-jobs] 881277: Use full image url in container buildx path https://review.opendev.org/c/zuul/zuul-jobs/+/881277 | 21:01 | |
@clarkb:matrix.org | corvus: I would expect rechecking the nodepool change sto be happy now? | 21:02 |
@jim:acmegating.com | agreed; recheck issued | 21:09 |
@clarkb:matrix.org | I think it worked. Stilla couple of jobs to run though | 21:51 |
-@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 881408: Improve FrozenJob.isEqual https://review.opendev.org/c/zuul/zuul/+/881408 | 22:00 | |
@clarkb:matrix.org | The nodepool chnage got a +1 | 22:16 |
@jim:acmegating.com | rechecking the operator change 881245. i think it was the same issue? | 22:22 |
@clarkb:matrix.org | wouldn't surprise me | 22:23 |
@clarkb:matrix.org | but not sure I looked at that one | 22:23 |
@jim:acmegating.com | oh no it was the dockerfile path one; but that merged | 22:24 |
@jim:acmegating.com | so let's see if it goes green now, if so, i think we're good | 22:24 |
@jim:acmegating.com | Clark: https://review.opendev.org/q/hashtag:quay | 22:25 |
@clarkb:matrix.org | yup I should hve a +2 on all of them | 22:26 |
@jim:acmegating.com | yes you do -- sorry was just pasting that since i just added the hashtag for easy dashboarding :) | 22:26 |
@clarkb:matrix.org | corvus: if you have time for https://review.opendev.org/c/opendev/system-config/+/881285 and its depends on (the depends on is more relevant to this channel) that would be good too. This is the opendev side of things and I updated the ensure-quay role in response | 22:27 |
@jim:acmegating.com | Clark: sure -- +2 on the jobs change, and some comments on the opendev one -- but i wonder if we want to think about putting the ensure-quay role in the opendev container base-jobs so that it's automatic. we would need to add a condition so it only ran on quay.io images... | 22:35 |
@clarkb:matrix.org | I think we could do that too | 22:36 |
@jim:acmegating.com | otherwise we might end up copying that pre playbook to a lot of repos | 22:36 |
@clarkb:matrix.org | I havne't been able to manually test the ensure-quay role yet after the refactor too. I can probably do that tomorrow (i did test the previous edition manually) | 22:36 |
@jim:acmegating.com | we could check for quay.io inside the loop, but then we might burn a lot of ansible tasks if it's unused... we could put a top-level boolean job variable to switch it on or of... | 22:37 |
@jim:acmegating.com | not sure the best approach | 22:37 |
@clarkb:matrix.org | I'll think about it. Responded to your comments on the system-config change | 22:38 |
-@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 880874: WIP: Add ZK load testing script https://review.opendev.org/c/zuul/zuul/+/880874 | 23:00 | |
-@gerrit:opendev.org- Zuul merged on behalf of Clark Boylan: [zuul/zuul-jobs] 877834: Add ensure-quay-repo role https://review.opendev.org/c/zuul/zuul-jobs/+/877834 | 23:08 | |
@clarkb:matrix.org | cool I'll work on testing ^ tomorrow and worst case I can push updates | 23:15 |
@clarkb:matrix.org | nothing is using it yet | 23:15 |
-@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul-operator] 881245: Publish container images to quay.io https://review.opendev.org/c/zuul/zuul-operator/+/881245 | 23:23 | |
@jim:acmegating.com | Clark: ^ okay i think we're past container image issues and on to bitrot issues for the operator | 23:23 |
@clarkb:matrix.org | looking | 23:24 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!