On Tue, Aug 16, 2016 at 3:33 PM, Randy Barlow <bowlofeggs@xxxxxxxxxxxxxxxxx> wrote: > 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. > > > Mirror Manager > -------------- > > 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. > > > docker > ------ > > 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 the metalink. If this is the case, I think we have quite a bit more work ahead for mirrormanager to make it able to work with lots of modules. Also, will we be signing the images, or is the using of metalink the only security 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 $randommirror 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 main blockers 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 just accept that users that are not running a fedora host can't run our images... _______________________________________________ infrastructure mailing list infrastructure@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/infrastructure@xxxxxxxxxxxxxxxxxxxxxxx
