a2dcc167a2
This allows the user to configure the registry to treat the first component of the repository as a namespace. Namespaces are completely separate from each other -- they have their own upload areas, and can have different content under the same repository name. In truth, we could omit this entirely and just use longer repository names. But treating it this way may have advantages later if we implement more of the API (e.g., for listing repositories). Or it may allow us to colocate a buildset registry and another registry on the same storage. Or we may, in the future, choose a different method for accessing the different namespaces (e.g., listening on a different port). Or it may be that we find some containers programs don't handle long repository names (I haven't seen that yet, but I haven't tested all of them). At any rate, the design was there from the start, and it's not that much code to implement it. To use this as a buildset registry, you must first choose whether to support docker or OCI tooling. If using, docker, only docker.io can be shadowed. If using OCI, docker.io and all other registries may be shadowed. Docker: * Do not enable the namespaced option. * Add to /etc/docker/daemon.json: "registry-mirrors": ["https://localhost:9000"] * Push and pull content into the registry as normal. OCI: * Enable the namespaced option. * Add to /etc/containers/registries.conf: [[registry]] prefix = "docker.io" location = "docker.io" [[registry.mirror]] location = "localhost:9000/docker.io" [[registry.mirror]] location = "docker.io" * Add similar entries for other registries * When pushing an image into the registry that shadows docker.io, use a command like: skopeo copy containers-storage:docker.io/test/registry \ docker://localhost:9000/docker.io/test/registry * Then a "podman pull docker.io/test/registry" will pull the image as expected. Change-Id: I88273a4a3e56971d2e2847fcd638d86d6bc491fc |
||
|---|---|---|
| playbooks/functional-test | ||
| tests | ||
| tools | ||
| zuul_registry | ||
| .gitignore | ||
| .gitreview | ||
| .stestr.conf | ||
| .zuul.yaml | ||
| bindep.txt | ||
| COPYING | ||
| Dockerfile | ||
| README.rst | ||
| requirements.txt | ||
| setup.cfg | ||
| setup.py | ||
| test-requirements.txt | ||
| tox.ini | ||
Zuul Registry
This is a container image registry for use with the Zuul project gating system.
The defining feature of this registry is support for shadowing images: it allows you to upload a local version of an image to use instead of an upstream version. If you pull an image from this registry, it will provide the local version if it exists, or the upstream if it does not.
This makes it suitable for use in a Zuul-driven speculative image pipeline.
The latest documentation for Zuul is published at: https://zuul-ci.org/docs/
Getting Help
There are two Zuul-related mailing lists:
- zuul-announce
-
A low-traffic announcement-only list to which every Zuul operator or power-user should subscribe.
- zuul-discuss
-
General discussion about Zuul, including questions about how to use it, and future development.
You will also find Zuul developers in the #zuul channel on Freenode IRC.
Contributing
To browse the latest code, see: https://opendev.org/zuul/zuul-registry To clone the latest code, use git clone https://opendev.org/zuul/zuul-registry
Bugs are handled at: https://storyboard.openstack.org/#!/project/zuul/zuul-registry
Suspected security vulnerabilities are most appreciated if first reported privately following any of the supported mechanisms described at https://zuul-ci.org/docs/zuul/user/vulnerabilities.html
Code reviews are handled by gerrit at https://review.opendev.org
After creating a Gerrit account, use git review to submit patches. Example:
# Do your commits
$ git review
# Enter your username if promptedJoin #zuul on Freenode to discuss development or usage.
License
Zuul-registry is free software licensed under the General Public License, version 3.0.
Python Version Support
Zuul requires Python 3. It does not support Python 2.