On Tue, Nov 10, 2015 at 1:08 PM, Adam Miller
<maxamillion(a)fedoraproject.org> wrote:
Hello all,
In the Fedora 24 timeframe the Fedora Release Engineering group is
aiming to deliver the Layered Image Build Service[0] to allow Fedora
contributors to build containers images. In the first iteration of
this we're targeting Docker layered image support. Part of this will
be to allow Fedora contributors to maintain Dockerfiles much like we
maintain rpm spec files via DistGit.
However we need to make a couple of decisions about naming conventions
such that we can distinguish between rpms and container images as they
are stored in Fedora DistGit. Also, alternatively we could setup a
completely separate DistGit for container images that is disjoint from
the one used for rpms. I would love feedback on everyone's preferences
between those two options.
If we were to go with the former rather than the latter, we would need
to find a way to "namespace" container images so they can be
determined as different. I've thought about this a lot and I worry
about defining a namespace by some alphanumberic sequence because I
just know that at some point there will end up being a piece of
software in the ecosystem that we want to package as a rpm that will
share this pattern and result in problematic filtering. We could
accept that risk and simply say "this sequence is a reserved word" or
use a special character as the leading character in a DistGit
repository name to signify that it is a container. A special character
is the option I propose.
Proposal:
In the event that container images (Dockerfiles for now, others in
the future) and rpm spec files are to share the DistGit repositories,
the container images leading character would be a special character.
The decision upon which special character is open to the community at
large to decide but certain ones impose obvious limitations for shell
quoting and the like. For the sake of example I will use the special
character '-' as my marker for a container image DistGit repository.
Also in the example I'm going to use the cockpit-project[1] as it is
already something that is packaged as an rpm[2] in Fedora and
delivered as a container image[3] built from it's Fedora rpm set.
Example:
Cockpit's rpm spec repo in DistGit would be stored as it is today:
fedpkg clone cockpit
Cockpit's Dockerfile repo in DistGit would be stored with a
leading special character:
fedpkg clone -cockpit
Here, the leading '-' signifies that it is the container image
DistGit repository which would make it an illegal name for an rpm by
the N-V-R convention.
The technical details of this are all open to change so feel free to
tell me I'm crazy and present a new idea and I'm happy to pursue it.
How much collaboration do we expect around the dockerfiles? I would
think significantly more than an RPM spec file. With an RPM, there
are only a handful of ways to build the software and adding patches
isn't a high-frequency/multi-maintainer event (usually).
If we expect dockerfiles to be more dynamic, then I would prefer a
separate git instance. Then we don't have to worry about collisions
and hacks. We can also set up a separate set of ACLs around who is
allow to commit to them, etc.
josh