On Mon, Aug 29, 2016 at 3:55 AM, Pierre-Yves Chibon <pingou@xxxxxxxxxxxx> wrote:
> 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/ :))
Not at present but I'm sure we could sort out adding that
functionality to loopabull.
-AdamM
>
>
> Pierre
>
> _______________________________________________
> infrastructure mailing list
> infrastructure@xxxxxxxxxxxxxxxxxxxxxxx
> https://lists.fedoraproject.org/admin/lists/infrastructure@xxxxxxxxxxxxxxxxxxxxxxx
>
_______________________________________________
infrastructure mailing list
infrastructure@xxxxxxxxxxxxxxxxxxxxxxx
https://lists.fedoraproject.org/admin/lists/infrastructure@xxxxxxxxxxxxxxxxxxxxxxx
