Ansible job definitions for Zuul
e7a0f0da8b
The docker registry daemon can either act as a private registry, or as a pull-through proxy, but not both. Yet we need to be able to serve private (speculative buildset) images as well as plain upstream images. Our registry is used as a mirror and requires authentication, therefore docker's normal behavior of falling back on docker.io won't work because it will attempt to use our credentials. However, the registry daemon stores all of its state in the filesystem, therefore we can run two instances of the registry service, both pointing at the same data store. The first acts as a pull-through proxy and will serve whatever files are already in the local storage, or will fetch them from docker.io. The second can be used to upload images into the local storage. To make a long story short, whenever we push into the buildset registry, we will use the second endpoint. Whenever the docker daemon pulls from the buildset registry, it will use the first. Change-Id: I296029068b5ef28ee56543741fe8c8deeefb5dfa |
||
|---|---|---|
| doc/source | ||
| playbooks | ||
| roles | ||
| tests | ||
| .gitignore | ||
| .gitreview | ||
| .stestr.conf | ||
| bindep.txt | ||
| LICENSE | ||
| README.rst | ||
| setup.cfg | ||
| setup.py | ||
| test-requirements.txt | ||
| tox.ini | ||
| zuul.yaml | ||
Zuul Jobs
This repo contains a set of Zuul jobs and Ansible roles suitable for use by any Zuul system.