On Mon, May 2, 2016 at 12:15 PM, Kevin Fenzi <kevin(a)scrye.com> wrote:
On Thu, 28 Apr 2016 15:47:57 -0500
Adam Miller <maxamillion(a)fedoraproject.org> wrote:
...snip...
>
> Workflow:
> OSBS will perform Builds, as these builds complete they will be
> pushed to the docker-distribution (v2) registry, these will be
> considered "candidate images". Pulp will sync and publish the
> candidate repository.
so, like updates-testing?
Yes, that's the hope/goal. I'd like the "flow" of the updates and
testing procedures to "feel" as close to how we do RPMs as possible.
(For all areas it makes sense)
> Testing will occur using the "candidate images" (details of how
> we want to handle that are outside the scope of this proposal).
ok. Hopefully we could add support for this to bodhi or some existing
setup.
+1 - That's the hope.
> A "candidate image" will be marked stable once it's criteria have
> been satisfied to do so. (This is vague because this is a topic of
> ongoing discussion and work to decide what criteria an image will
> need to abide by before being considered "stable" and promoted as
> such)
>
> Once stable, pulp will publish that repository's content to a
> directory, we will split that content and sync the image layers along
> with their metadata to Mirror Manager master mirror. We will also
> sync the repo metadata published by Pulp to somewhere Crane can pick
> it up. (This could and will likely be something that Bodhi triggers
> via the Pulp REST API)
How big / many files is a typical container?
That's hard to say, the images can vary heavily depending on what they
contain (how many packages and deps? are they java? etc). For just the
base image, we're currently sitting at 204.7MB, so that will be the
starting layer upon which everything else is built. At this time, the
cockpit image is 579MB and is the first image we're targeting shipping
(it more or less sparked the whole project to deliver layered images
as official Fedora content).
> Mirror Manager will Pulp distribute to the mirrors the image
> layers and their metadata.
Can you expand on what you mean by pulp distribute here?
Ah, sorry. This was a mental slip. Pulp will "publish" the layers and
their metadata and we then can copy/rsync/$other that to anywhere that
MirrorManager can then mirror the content.
Mirrors rsync from us to distribute content. There is pretty much 0
chance we can get them all to run pulp.
> Crane will get the new repository metadata and will serve
> redirects to the new content relative to
download.fedoraproject.org
> which will perform another redirect (via MirrorManager) where the
> docker client upon a "docker pull" will find it's content.
>
>
> I have put together an ascii diagram in hopes that it will assist in
> seeing the full picture.
>
>
https://maxamillion.fedorapeople.org/FedoraPulpDocker.txt
>
> (I couldn't get it to paste cleanly into my email client)
>
> If there are any questions, comments, or feedback please let me know.
So, I am wondering how important pulp is here. I guess we need it to
create manifests? Might there be a smaller tool to do that?
Pulp is kind of the worker bee behind all this, it takes the docker
registry data and spits it out in a way that we can serve it from
Crane without needing all our mirrors to be running something that
implements the registry API. I don't know of anything that satisfies
this need that is a smaller application, but if there is one that
others know of then I'm open to suggestion. It also handles the
promotion of content and provides a REST API to accomplish those tasks
for easy-ish integration with other tools.
Sounds like we need to expose crane for incoming pull requests, but
everything else is internal?
Yes, Crane will be exposed but everything else can be internal.
-AdamM
>
> kevin
>
> _______________________________________________
> rel-eng mailing list
> rel-eng(a)lists.fedoraproject.org
>
http://lists.fedoraproject.org/admin/lists/rel-eng@lists.fedoraproject.org
>