On Thu, 28 Apr 2016 17:52:44 -0500
Adam Miller <maxamillion(a)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?
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?
And any guidelines on naming? Just use common sense? They will have to
be unique.
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.
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?
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?
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. ;)
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).
Also, we will need to make pkgdb create components for each container
as well for people to report bugs against.
kevin