On Mon, May 2, 2016 at 12:07 PM, Kevin Fenzi <kevin(a)scrye.com> wrote:
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 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
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
> Docker Layered Image "packaging" Guidelines 
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
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 
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 
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).
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.
> devel mailing list