On Tue, Nov 10, 2015 at 12:35 PM, Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx> wrote: > On Tue, Nov 10, 2015 at 1:08 PM, Adam Miller > <maxamillion@xxxxxxxxxxxxxxxxx> 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). > I'm honestly not entirely sure. I think that will just kind of organically happen. I would like to try and get a sense of what people would like to come out of it though so that we can cater to the preferred workload. > 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. That's definitely an option. I'm open to either but we can do that now with what's surrounding DistGit. -AdamM > > josh > -- > devel mailing list > devel@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
