Consider support for distributing docker images in conjunction with Pulp

[ralphbean]

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:

• someone will kick off a container build with fedpkg
• that will call koji
• which will in turn call a container build plugin.
• which will in turn call OSBS to build the container
• OSBS will then contact Pulp Crane to tell it about the image (and upload it)

... 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]

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.

[mdomsch]

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
#160 (comment)
.

[ralphbean]

❤️ @mdomsch++ ❤️

[mdomsch]

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

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

—
Reply to this email directly or view it on GitHub
#160 (comment)
.