On Tue, Aug 16, 2016 at 3:33 PM, Randy Barlow
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.
Putting this on port 5000 wouldn't be a big issue I'd say.
We will need to make a few changes to Mirror Manager as well. We will
need to provide an interface to allow mirror admins to opt in/out of
mirroring Docker content. We will also need to modify the curler to
detect whether a given mirror is up to date or not. We will need to make
sure that UMDL is updated when content changes.
The most significant work required will likely be modifying the docker
client to enable it to properly handle the metalink responses it will be
receiving from Mirror List. When requesting the manifest, it will
receive a metalink document that will give it a priority ordered list of
mirrors. It will need to work through the list in order until it reaches
a mirror that has the correct checksum for the requested manifest. It
will then use that same mirror for the subsequent blob requests.
So, we get a mirrormanager module (previously called repo) for each different
container we ship? Since currently the metalink level is on repo-arch, and that
is the level on which it retains and sends the checksums as part of
If this is the case, I think we have quite a bit more work ahead for
to make it able to work with lots of modules.
Also, will we be signing the images, or is the using of metalink the
people get? Since I can guarantee you that some people will feel like
their closest mirror
is from their competitor and not want to use it, or that they hit
mirrorlist at one point
when it's down, and they will stop using the metalink, and just insert
directly, and use that.
I would want to make sure that even if they do this, they still get some sort of
verification of the data. This was previously mentioned as one of the
for getting this stuff mirrored out.
There is some concern that such a feature would not be accepted by the
upstream docker project. If we were to proceed with this proposal, we
would propose this patch to the upstream Docker project. If upstream
were not willing to accept the feature, we would need to have the Fedora
docker packager carry this patch as a downstream add on.
So that would mean that the Fedora docker images are only available for
people that try to run it on a Fedora host or that we manually tell
"Yeah, use this mirror url that's outside of our control"? I'm not
sure that this
will go over smoothly with other people..
Do you have any idea how likely it is to get this patch accepted into upstream?
From what I've heard, the Docker people are not really happy about merging
distro-specific things, so this is a considerable risk, unless we will
that users that are not running a fedora host can't run our images...