On Mon, May 2, 2016 at 12:07 PM, Kevin Fenzi <ke...@scrye.com> wrote: > On Thu, 28 Apr 2016 17:52:44 -0500 > Adam Miller <maxamill...@fedoraproject.org> wrote: > >> Hello all, >> We're wrapping up the first phase of the Fedora Docker Layered >> Image Build Service[0] and the time has come to start thinking about >> what we as a Project need to do to formalize what it means to be >> shipping Docker Layered Images once we are capable of building and >> distributing them. >> >> These are effectively going to compliment their RPM counterpart >> at least in the beginning since we as a Project have never shipped >> any build artifact other than RPMs as a part of the distribution >> before. We can grow organically from there if we want to extend >> beyond the initial offering for Docker Layered Images but I thought >> following RPM as a guide in the beginning was a reasonable goal to >> achieve. Some areas that seemed pertinant right off the bat are >> below, for each of them I have alread created a Draft document that I >> would appreciate feedback on. > > So, at least at first it's assumed there will just be one rpm in each > container? Or can we have a collection of rpms that make sense to be > together?
Collection of RPMs is fine, the goal is just not to ship non-rpm code or content yet outside of Docker-ized application control scripts where needed/applicable. > >> Docker Layered Image "packaging" Guidelines [1] > > Whats the difference here between version and release? Does version > change any based on the version of the primary rpm in the container? It shouldn't but it can in the future, I was more or less replicating this information in the beginning to hopefully leave some space for this to change in the future of the Fedora Modularization efforts because a module could potentially have it's own versioning scheme outside of the content inside of it. > > And any guidelines on naming? Just use common sense? They will have to > be unique. Yes, need to be unique. This is going to follow the RPM naming guidelines for now. > > I guess the build system has network access and people can put anything > in CMD lines? How can we make reproducible builds? Or should CMD be > restricted to only some network resources. The build system does currently but ultimately doesn't need it since we can inject internal Fedora mirrors into the build environment that the container is built in. Which is something we may or may not want to do. The CMD lines likely need some guidelines around them and should be added to the doc. > >> Package Review Process with a Docker Containers section [2] > > This might be better as a Container review process seperate from the > Package review process, ie a different page? Yes, it very well could be. I just put them together as a first pass effort to get feedback from others. I'm open to them being separate and don't have a real preference here. > > So it's assumed here that someone is a packager to submit new container > reviews? Or would we want some kind of 'containerger' role for people > who maintainer containers? That's up for discussion. I think they should be separate because being well versed in creating Docker images doesn't inherently mean someone is well versed in creating RPMs, just as the inverse is not inherently true. I've in the past gotten some flack for that opinion so I'd definitely like that to be opened up to more discussion. > >> Docker Layered Images Naming Guildelines [3] > > I am not sure what to add to make this more concrete, but I think it > needs to be. ;) Agreed, I was hoping others could help fill in the blanks. :) >> >> The Fedora Cloud SIG has done a first-pass review of these (thanks >> Cloud SIG!) so hopefully there's a certainly level of sanity to them >> but I'm absolutely open to new ideas and extending the content with >> more coverage. >> >> Another point to note is that we need to determine how this should be >> handled in BZ components for bug reporting as well as for filing >> review requests. > > I agree with the folks downthread we can make a bugzilla "Container > Review" to compliment Package Review. Unless we think we can spin up a > review application for these (like we are still hopefully planning on > doing for packages someday). +1 > > Also, we will need to make pkgdb create components for each container > as well for people to report bugs against. +1 - I'm honestly not sure how to go about that, I assume I need to send a request to BZ folks somehow but how BZ is admin'd/hosted is a bit of a black box to me. I would appreciate advisement on that. -AdamM > > kevin > > -- > devel mailing list > devel@lists.fedoraproject.org > http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org > -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
