[RFC] DistGit Container Image namespacing for Layered Image Build Service

[Ralph Bean]

On Thu, Nov 12, 2015 at 03:01:49PM -0500, Ray Strode wrote:
> Hi,
> 
> On Tue, Nov 10, 2015 at 1:08 PM, Adam Miller
> <maxamillion at fedoraproject.org> wrote:
> > 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.
> 
> git repositories normally use '/' to separate namespaces, so i'd propose
> 
> $ fedpkg clone containers/cockpit
> 
> and maybe add support for
> 
> $ fedpkg clone srpms/cockpit
> 
> at the same time.
> 
> This has the added benefit that cgit will automatically filter docker
> reposistories when you visit, e.g,
> 
> http://pkgs.fedoraproject.org/cgit/containers/

I like this too.  Here are three thoughts:

Perhaps, we use 'dockerfiles' for the prefix instead of 'containers',
because presumably there will be some whole new way to build
containers in 2017, and we'll need to keep our dockerfiles/ repos
separate from our awesomefiles/ repos.

We could also use this opportunity to move the kickstarts (another
input to koji builds) away from https://fedorahosted.org/spin-kickstarts
and over to dist-git as well, with a namespace like 'kickstarts/kde'
and 'kickstarts/lxde'.

The existing rpm content could be moved to a 'specfiles/' namespace
(or maybe 'srpms/'?) but we could further add some apache httpd rules that
respond with a redirect to the 'srpms/' namespace if the requests to
the base namespaceless-namespace level are met with a 404. -- "when in
doubt, default to srpms/".  That might help keep some of our existing
tools working as-is without too much catastrophe.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20151113/cf637534/attachment.sig>