search

fedora-infra / mirrormanager2

Rewrite of the MirrorManager application in Flask and SQLAlchemy
https://mirrormanager.fedoraproject.org
GNU General Public License v2.0
65 stars 49 forks source link

Consider support for distributing docker images in conjunction with Pulp #160

Open ralphbean opened 8 years ago

ralphbean commented 8 years ago

In particular in conjunction with Pulp crane. @maxamillion and fedora releng are the stakeholders here.

I believe the way the production is going to work is that:

... that's all I know at this point. People could then list the images in pulp and download what they want.

A missing piece of the puzzle is that we would like to somehow leverage our mirror infrastructure to distribute those images. It would be nice to have pulp crane redirect download requests to the right place.

ralphbean commented 8 years ago

Thinking out loud here... MM2 does a number of things. Among them:

So, if we have pulp simply put the containers in place on the master mirror, then both of those phases should just work.

Proposal: The dynamically generated mirrorlist intended for clients is another story. When people go to pull down the images from crane, they'll be hitting its API, I presume. Crane would then need to somehow take the metadata about the request (the IP and the requested resource) and forward that to the mirrorlist behind the scenes. Mirrorlist could then return a list of possible mirrors which Pulp then forwards back to the client.

This would require 1) a patch or plugin to pulp which does the backend query to mirrorlist and 2) a patch to mirrorlist to serve requests on behalf of another service - i.e., it would have to accept an IP as a querystring argument, or an X-Forwarded-Host HTTP header on the request, or something like that.

mdomsch commented 8 years ago

Mirror list already takes ?ip= query argument, as well as parses out x-forwarded-for headers. On Feb 8, 2016 4:13 AM, "Ralph Bean" notifications@github.com wrote:

Thinking out loud here... MM2 does a number of things. Among them:

  • It scrapes the master mirror to figure out what should be on the remote mirrors.
  • It scrapes the remote mirrors to figure out what they do and don't have with respect to that master list.

So, if we have pulp simply put the containers in place on the master mirror, then both of those phases should just work.

Proposal: The dynamically generated mirrorlist intended for clients is another story. When people go to pull down the images from crane, they'll be hitting its API, I presume. Crane would then need to somehow take the metadata about the request (the IP and the requested resource) and forward that to the mirrorlist behind the scenes. Mirrorlist could then return a list of possible mirrors which Pulp then forwards back to the client.

This would require 1) a patch or plugin to pulp which does the backend query to mirrorlist and 2) a patch to mirrorlist to serve requests on behalf of another service - i.e., it would have to accept an IP as a querystring argument, or an X-Forwarded-Host HTTP header on the request, or something like that.

— Reply to this email directly or view it on GitHub https://github.com/fedora-infra/mirrormanager2/issues/160#issuecomment-181288142 .

ralphbean commented 8 years ago

:heart: @mdomsch++ :heart:

mdomsch commented 8 years ago

Awww, and Valentine's is this week too. Thanks Ralph! On Feb 8, 2016 6:57 AM, "Ralph Bean" notifications@github.com wrote:

[image: :heart:] @mdomsch https://github.com/mdomsch++ [image: :heart:]

— Reply to this email directly or view it on GitHub https://github.com/fedora-infra/mirrormanager2/issues/160#issuecomment-181355166 .