On Fri, Nov 13, 2015 at 05:34:21PM -0600, Adam Miller wrote: > On Fri, Nov 13, 2015 at 5:14 PM, Brian C. Lane <bcl@xxxxxxxxxx> wrote: > > On Tue, Nov 10, 2015 at 12:08:25PM -0600, Adam Miller 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. > > > > So you're talking about one docker file per package, right? Or are these > > going to pull from multiple packages and have the docker container be a > > different level of object? Or both? > > Both, it's mostly at the discretion of the person attempting to > deliver something in a container. Some may be simple "I added httpd on > top of the base Fedora Docker image" and others might be "I put all of > ownCloud into a container so you can just run the whole thing with > this one command" > > That being said, I'm not married to the concept. It was just the idea > going into it. If the general consensus among the community is "one > Dockerfile to one package" we could go that route. > > > > > If you're talking about a 1:1 package:docker mapping then the only thing > > that makes sense to me is to have them live in the current system next > > to the .spec files. Anything else will easily introduce divergence from > > the rpm packages. > > Absolutely, so far there has been the expectation that there will be > divergence because of the more "dynamic" nature of what containers > bring to the table. Ok, that makes sense. So some packages may also have docker images but most of this will be more along the lines of a spin for a specific collections of packages built from our existing rpms. > > I also see that 'container packager' and 'rpm packager' are used in the > > build service page. I don't think these should be separate roles, > > everyone should be a packager. If you have one role working on container > > building for a package and another who only does rpm packaging we're > > going to, again, end up with things diverging. > > I believe they will diverge naturally as time goes on. Also, I don' t > think everyone who has rpm packaging expertise is well versed in the > ways of Docker and vice versa. I think packagers should be familiar with both if we're going to be producing both. Current rpm maintainers have a body of knowledge surrounding their packages and upstreams that should not be lost or ignored when using them for Docker images. > > Some things I'd suggest (given I don't know the answers to the above > > questions): > > > > 1. All bits have to come from koji built rpms. No rebuilding of bits > > for docker, it just installs existing bits. > > That is the plan, but configuration can take place inside the context > of the container image build process to allow for single-command > execution. Sure, that's the big benefit of Docker, reasonable configuration of existing packages makes sense. As long as that's where it stops and the binaries are the same as what we produce with the rpms. I don't want to see us rebuilding things for the Docker container and using different binaries or pulling in external dependencies that aren't already packaged as an rpm. > > 2. docker files for packages live in dist-git next to the package spec > > file. > > We can, pending the agreement that's all we as a community/project use > Dockerfiles for. The original idea going in to this though is that we > could extend this to provide a more full featured solution for > services that would need more than one package. Even simple things > like httpd modules (mod_wsgi, mod_php, etc) would technically ship > more rpms than they produce in the docker image. > > Also in the distant future (out of scope for the original offering), > we'd like to look at delivering multi-container apps via Nulecule[0] > specifications. > > > > > 3. Any meta-containers collecting using packages are also an rpm > > package, following whatever naming convention gets decided on. > > fedora-docker-foo would make sense to me. > > I'm not sure I follow what you mean here, why would something that > only comes as a Dockerfile also be a rpm? What I'm thinking is that dist-git doesn't have to always produce an rpm. If the package has both, then a fedpkg build produces both, and we can add fedpkg build --rpm and fedpkg build --docker. If a package only has a docker file then it only produces a docker image. This reuses the tooling we are all familiar with, and keeps everything in the same place. Use a container specific naming convention and it can be expanded to support other containers as they become popular. > > 4. package level docker files are maintained by the same people who maintain > > the package. > > > > This certainly makes sense if we end up going the package:container > 1:1 route. I think it makes sense either way. Much of the packaging guidelines should still apply to creating containers. -- Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT) -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
