On Wed, Aug 24, 2016 at 06:25:15PM -0400, Randy Barlow wrote:
Mirror List
-----------
Users will be pointing their docker clients at Mirror List when they
docker pull Fedora's Docker images. In order for this to work, we will
need to make two changes to Mirror List so that it can respond to the
docker client properly. The first change is that Mirror List will need
to respond with a special header and a body of "{}" when the docker
client sends a GET request for /v2/. The second change is that it will
need to return a Docker Manifest schema 2 document containing a list of
mirrors that have the requested blobs when the client makes additional
requests, so that the clients can be retrieve the blobs from a list of
mirrors near their locations, similar to how it does with the dnf
client today.
The docker client typically connects to port 5000. We could run a
second instance of Mirror List on port 5000 if we wanted to isolate it
from the current instance. We can also have the docker client pull from
443 as dnf does if we want to keep the deployment simpler.
I am wondering if it would make sense to have a new mirrorlist-docker that would
be different from the actual/current mirrorlist. It would allow easier
modifications and evolutions w/o running into the risk of breaking the current
mirrorlist.
New Tool
--------
The last piece that is needed is a tool that can create the filesystem
tree that we want to synchronize out to the mirrors. The mirrors only
need to carry manifests and blobs, so the tool needs only to pull these
documents out of the registry that Adam Miller has set up and write
them to disk in a particular structure. For optimization, we could use
hardlinks for blobs that are common across the various images (for
example, the Fedora base blob will be the same in all images) to save
rsync time and mirror disk space.
Additionally, we will need a playbook to run this new tool in response
to fedmsgs. We may be able to use Adam Miller's loopabull project to
run such a playbook at the right times.
Does loopabull work with our setup that relies sudo?
(I still think we can do w/o but I won't fight if we want to do w/ :))
Pierre