RFC: Fedora Docker Layered Image Guidelines

[Adam Miller]

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.

    Docker Layered Image "packaging" Guidelines [1]

    Package Review Process with a Docker Containers section [2]

    Docker Layered Images Naming Guildelines [3]

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.

Something else what was brought up when I originally submitted these ideas to
FESCo[4] (aside from the fact that this should go to devel list first) was
that it is probably a good idea to establish a Container-centric Guidelines
Committee much in the way there is a Fedora Packaging Committee (which focuses
on RPMs). My question to everyone on that topic is, would there be enough
interest to establish such a committee?

As a side note and just a matter of opinion but I think the idea of forming
a Committee to help shepherd these new types of deliverables through Fedora
will help to enable aspects of Fedora Modularization[5] which ultimately will
be good for the whole of the Fedora Project.

I look forward to questions and feedback.

Thank you,
-AdamM


[0] - https://fedoraproject.org/wiki/Changes/Layered_Docker_Image_Build_Service
[1] - https://fedoraproject.org/wiki/PackagingDrafts/Containers
[2] -
https://fedoraproject.org/wiki/PackagingDrafts/Package_Review_Process_wit...
[3] - https://fedoraproject.org/wiki/Draft/Packaging:DockerLayeredImageNamingGu...
[4] - https://fedorahosted.org/fesco/ticket/1573

[Daniel J Walsh]

Hopefully we are looking at getting docker-squash/docker-scripts 
involved in squashing images

built from the service.  At least optionally if not required.

docker-squash should allow you to squash everything in the Dockerfile 
back to the from line.

from=$(awk '/^FROM/{print $2}' ~/Dockerfile)

docker-squash -f ${from} -t SQUASHEDTAGNAME --output-path /images 
UNSQUASHEDIMAGENAME

On 04/28/2016 06:52 PM, Adam Miller 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.
>
>       Docker Layered Image "packaging" Guidelines [1]
>
>       Package Review Process with a Docker Containers section [2]
>
>       Docker Layered Images Naming Guildelines [3]
>
>  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.
>
>  Something else what was brought up when I originally submitted these ideas to
>  FESCo[4] (aside from the fact that this should go to devel list first) was
>  that it is probably a good idea to establish a Container-centric Guidelines
>  Committee much in the way there is a Fedora Packaging Committee (which focuses
>  on RPMs). My question to everyone on that topic is, would there be enough
>  interest to establish such a committee?
>
>  As a side note and just a matter of opinion but I think the idea of forming
>  a Committee to help shepherd these new types of deliverables through Fedora
>  will help to enable aspects of Fedora Modularization[5] which ultimately will
>  be good for the whole of the Fedora Project.
>
>  I look forward to questions and feedback.
>
>  Thank you,
>  -AdamM
>
>
>  [0] - https://fedoraproject.org/wiki/Changes/Layered_Docker_Image_Build_Service
>  [1] - https://fedoraproject.org/wiki/PackagingDrafts/Containers
>  [2] -
> https://fedoraproject.org/wiki/PackagingDrafts/Package_Review_Process_wit...
>  [3] - https://fedoraproject.org/wiki/Draft/Packaging:DockerLayeredImageNamingGu...
>  [4] - https://fedorahosted.org/fesco/ticket/1573
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  http://lists.fedoraproject.org/admin/lists/[e-mail]
>
>

[Colin Walters]

On Thu, Apr 28, 2016, at 06:52 PM, Adam Miller wrote:

>      Docker Layered Image "packaging" Guidelines [1] 
This current design means Dockerfiles are always secondary shims.
I think the most interesting case is for new services which are
Docker/container only at least upstream.  

Do we e.g. require systemd unit files for the RPM that contains the code?
I don't think we should, but the current page says "packaged properly as
RPMs"
which implies all current RPM requirements.

[Matthew Miller]

On Fri, Apr 29, 2016 at 08:55:02AM -0400, Colin Walters wrote:
>  >     Docker Layered Image "packaging" Guidelines [1]
>  This current design means Dockerfiles are always secondary shims.
>  I think the most interesting case is for new services which are
>  Docker/container only at least upstream.   
We need to have a good way to track the contents, both the
distro/"packager" level and at the sysadmin/user level, so we can do
security updates. I hope we can get there for non-RPM content, but I
don't think we're even close. So this gives us a reasonable, not so
scary starting point from which we can expand.

See
https://lists.fedoraproject.org/archives/list/[e-mail].o...


-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Adam Miller]

On Fri, Apr 29, 2016 at 7:55 AM, Colin Walters <walters(a)verbum.org&gt; wrote:
>  On Thu, Apr 28, 2016, at 06:52 PM, Adam Miller wrote:
>
> >     Docker Layered Image "packaging" Guidelines [1]
>
>  This current design means Dockerfiles are always secondary shims.
>  I think the most interesting case is for new services which are
>  Docker/container only at least upstream.
>  
Yes, for now that is the case. In the future we want to enable
Docker-only content, but the current thought is to start small before
opening the floodgates and then work  to make sure we have some level
of validation along the pipeline. We have validation in place for RPMs
and we will eventually for Docker Images, just not there yet.

>  Do we e.g. require systemd unit files for the RPM that contains the
> code?
>  I don't think we should, but the current page says "packaged properly as
> RPMs"
>  which implies all current RPM requirements. 
Yes, the initial goal here is to just wrap pre-existing sets of RPMs
into Docker Images to provide out-of-the-box runnable services. From
there we can decide what all we want to do with these and what
capabilities will be required to enable a more flexible workflow in
the future.

> --
> devel mailing list
> devel(a)lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/[e-mail]

[Subhendu Ghosh]

If we assume that image is immutable, how does one expect the applications
configuration and data to be managed? Are there additional ENV handlers
inside the container that might not be present otherwise in the RPM world?
Is there are requirement for volume mounts for certain locations inside the
container?  Should that be expressed via labels?


-subhendu

[Adam Miller]

On Sun, May 1, 2016 at 10:26 AM, Subhendu Ghosh <sghosh151(a)gmail.com&gt; wrote:
>  If we assume that image is immutable, how does one expect the
> applications
>  configuration and data to be managed? Are there additional ENV handlers
>  inside the container that might not be present otherwise in the RPM world?
>  Is there are requirement for volume mounts for certain locations inside the
>  container?  Should that be expressed via labels? 
+1

Yes, that's something we should likely handle in the guidelines.


-AdamM

>
> -subhendu
>
>
> --
> devel mailing list
> devel(a)lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/[e-mail]
>

[Matthew Miller]

On Thu, Apr 28, 2016 at 05:52:44PM -0500, Adam Miller wrote:
>  Something else what was brought up when I originally submitted these
> ideas to
>  FESCo[4] (aside from the fact that this should go to devel list first) was
>  that it is probably a good idea to establish a Container-centric Guidelines
>  Committee much in the way there is a Fedora Packaging Committee (which focuses
>  on RPMs). My question to everyone on that topic is, would there be enough
>  interest to establish such a committee? 
I hope there's enough interest. If it seems like not quite enough,
maybe the currently-on-ice Enviroments & Stacks group would be
appropriate. Although it went in a different direction, that was part
of my original idea for the group.

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Matthew Miller]

On Thu, Apr 28, 2016 at 05:52:44PM -0500, Adam Miller wrote:
>  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. 
Maybe a "Fedora Containers" bugzilla product, so we have a different
namespace from RPMs?

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Ralph Bean]

On Fri, Apr 29, 2016 at 12:59:40PM -0400, Matthew Miller wrote:
>  On Thu, Apr 28, 2016 at 05:52:44PM -0500, Adam Miller wrote:
>  > 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.
>  
>  Maybe a "Fedora Containers" bugzilla product, so we have a different
>  namespace from RPMs? 
That sounds like a great idea to me.

Similarly, we have a docker/ namespace in pkgdb, from which we could pull the
default contact for bugs on a component in the Fedora Containers
product (as well as the list of watchbugzilla people).

[Kevin Fenzi]

On Thu, 28 Apr 2016 17:52:44 -0500
Adam Miller <maxamillion(a)fedoraproject.org&gt; 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

[Adam Miller]

On Mon, May 2, 2016 at 12:07 PM, Kevin Fenzi <kevin(a)scrye.com&gt; wrote:
>  On Thu, 28 Apr 2016 17:52:44 -0500
>  Adam Miller <maxamillion(a)fedoraproject.org&gt; 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(a)lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/[e-mail]
>

[Kevin Fenzi]

On Tue, 3 May 2016 11:22:30 -0500
Adam Miller <maxamillion(a)fedoraproject.org&gt; wrote:

>  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. 
ok. 
>  
>  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. 
Has it been decided that modules are docker containers? 

>  > 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. 
Well, sure, but say I make a container that is some web app + web
server + database. Do I call it by the app name? The web server name? A
combo?

>  > 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. 
Yeah, if we aren't restricting the network for builds, anyone can do
anything in a CMD line right? and since it depends on something
outside in the net it may be changed or gone later when we rebuild. 
 
>  > 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. 
Sure. I think seperate would be ok. 

>  > 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. 
Fedora Infrastructure has a admin user that can create components and
such under the "Fedora" Product. So, just a infrastructure ticket would
be the way to go. 

kevin

[Josh Boyer]

On Tue, May 3, 2016 at 1:32 PM, Kevin Fenzi <kevin(a)scrye.com&gt; wrote:
>  On Tue, 3 May 2016 11:22:30 -0500
>  Adam Miller <maxamillion(a)fedoraproject.org&gt; wrote:
>
> > 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.
>
>  ok.
> >
> > 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.
>
>  Has it been decided that modules are docker containers? 
No.  AIUI, a docker container is one potential delivery artifact for a
module.  There are others, such as RPM repos.  So it is not a strict
"modules are containers" mapping.

josh

[Adam Miller]

On Tue, May 3, 2016 at 12:32 PM, Kevin Fenzi <kevin(a)scrye.com&gt; wrote:
>  On Tue, 3 May 2016 11:22:30 -0500
>  Adam Miller <maxamillion(a)fedoraproject.org&gt; wrote:
>
> > 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.
>
>  ok.
> >
> > 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.
>
>  Has it been decided that modules are docker containers? 
Not to the best of my knowledge, but afaik modules could be containers
and/or optionally be distributed as such.
> > > 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.
>
>  Well, sure, but say I make a container that is some web app + web
>  server + database. Do I call it by the app name? The web server name? A
>  combo? 
So a question around this topic has come up recently on IRC, I was
hoping to see it make it to the mailing list but it has not.

Something we've not yet addressed yet and that we really need to, is
how to handle multi-service containers *OR* multi-container services
(I was secretly hoping to have a Container Guidelines SIG exist that
could hash this out).

Providing an all-in-one docker image is certainly something we can do
such that the container image provides web server + database + web
app, but it seems more popular to have each element (server, database,
app) be placed into it's own container and have them be "wired"
together via some tooling. There's many examples of open source
multi-container orchestration solutions[0][1][2][3][4][5][6] (and
likely others I'm not familiar with). Also, the Project Atomic
upstream group has an open specification for how to define these
multi-container services called Nulecule[7] that is meant to be
independent of the backend implementation of container orchestration
engine but simply a definition template/spec which is something I'd
also like to see considered.

As a side note, there's a reference implementation of the Nulecule
spec called Atomic App[8] that might also be worth while for
consideration from the group on the topic.

> > > 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.
>
>  Yeah, if we aren't restricting the network for builds, anyone can do
>  anything in a CMD line right? and since it depends on something
>  outside in the net it may be changed or gone later when we rebuild. 
This is true and is probably something we should address in the near
term. I'll work on this in the staging environment and report back.

> > > 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.
>
>  Sure. I think seperate would be ok. 
+1

> > > 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.
>
>  Fedora Infrastructure has a admin user that can create components and
>  such under the "Fedora" Product. So, just a infrastructure ticket would
>  be the way to go. 
+1 Thank you.

There's still plenty to be considered around all of this, looking
forward to continued feedback from everyone. :)

-AdamM

[0] - https://www.openshift.com
[1] - http://kubernetes.io/
[2] - https://github.com/docker/swarm
[3] - https://github.com/docker/compose
[4] - https://dcos.io/
[5] - http://deis.io/
[6] - https://www.cloudfoundry.org/
[7] - https://github.com/projectatomic/nulecule
[8] - https://github.com/projectatomic/atomicapp


>
> kevin
>
>
>
> --
> devel mailing list
> devel(a)lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/[e-mail]
>

[James Hogarth]

On 4 May 2016 at 21:48, Adam Miller <maxamillion(a)fedoraproject.org&gt; wrote:

>  On Tue, May 3, 2016 at 12:32 PM, Kevin Fenzi <kevin(a)scrye.com&gt;
> wrote:
>  > On Tue, 3 May 2016 11:22:30 -0500
>  > Adam Miller <maxamillion(a)fedoraproject.org&gt; wrote:
>  >
>  >> 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.
>  >
>  > ok.
>  >>
>  >> 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.
>  >
>  > Has it been decided that modules are docker containers?
>
>  Not to the best of my knowledge, but afaik modules could be containers
>  and/or optionally be distributed as such.
>  >
>  >> > 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.
>  >
>  > Well, sure, but say I make a container that is some web app + web
>  > server + database. Do I call it by the app name? The web server name? A
>  > combo?
>
>  So a question around this topic has come up recently on IRC, I was
>  hoping to see it make it to the mailing list but it has not.
>
>  
Sorry Maxamillion ... trying hard to find the time between home and work to
do any of this stuff ;)



>  Something we've not yet addressed yet and that we really need to,
> is
>  how to handle multi-service containers *OR* multi-container services
>  (I was secretly hoping to have a Container Guidelines SIG exist that
>  could hash this out).
>
>  
Specifically I'd really like to see the ownCloud packages several of us
have worked hard on to become Fedora containers under the layered image
service.

The interesting thing with this as a Fedora container application is the
matrix of configuration possibilities that someone may want to use:

In a single deployed container:
httpd+mysql
httpd+postgresql
nginx+mysql
nginx+postgresql

In a multi container orchestration:
httpd+remoteDB
nginx+remoteDB

Of course the questions would be left of how to provide readmes or similar
guidelines for users to have persistent storage (for owncloud this would by
/var/lib/owncloud persisted for data along with DB storage) and to be able
to provide things like SSL certs to the webserver instance, if SSL was an
optional thing this might potentially double the above matrix for ssl and
non-ssl versions.

Of course being able to provide several different versions that fulfill the
various preferences and needs of people would mean a layered docker image
of 'owncloud' wouldn't really meet expectations.

Either there would need to be different components each in their own
dist-git repo or the owncloud dit-git would need the capability of building
the container, with unique names, from multiple branches.

>  Yeah, if we aren't restricting the network for builds, anyone can
> do
>  > anything in a CMD line right? and since it depends on something
>  > outside in the net it may be changed or gone later when we rebuild.
>
>  This is true and is probably something we should address in the near
>  term. I'll work on this in the staging environment and report back.
>
>  
I can't help but feel we'd be better off not permitting arbitrary external
access in CMD but requiring something similar to the lookaside cache for
pulling in artifacts external to the Fedora RPMs.


>  >
>  >> > 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.
>  >
>  > Sure. I think seperate would be ok.
>  
I imagine this will also depend on how it's handled in git and with naming
of the image and what's considered a component from a bugzilla perspective.

We'd definitely want to separate container bugs from application bugs
though.


>  There's still plenty to be considered around all of this, looking
>  forward to continued feedback from everyone. :)
>
>
>  
From our oC 8.2 builds onwards it's a pretty clean setup for the spec and
dependencies - is there some sort of playground area we can start doing
some testing within in order to being providing some more informed, rather
than theoretical, feedback?

I'm not sure how feasible this would be but it would be nice to be able to
describe the container via ansible roles. I have a setup that generates
Fedora VMs for each of the httpd/nginx/mysql/postgres combinations  to make
testing easier on my life as a packager, being able to almost directly use
that framework would be very useful.

[Dennis Gilmore]

On Tuesday, May 3, 2016 11:32:22 AM CDT Kevin Fenzi wrote:
>  On Tue, 3 May 2016 11:22:30 -0500
>  
>  Adam Miller <maxamillion(a)fedoraproject.org&gt; wrote:
>  > 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.
>  
>  ok.
>  
>  > 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.
>  
>  Has it been decided that modules are docker containers? 
Right now modules are repos of rpms. 

>  > > 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.
>  
>  Well, sure, but say I make a container that is some web app + web
>  server + database. Do I call it by the app name? The web server name? A
>  combo? 
I would say the web app, thats teh things people would want to install, the 
web server and db could/would be inherited layers 

>  > > 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.
>  
>  Yeah, if we aren't restricting the network for builds, anyone can do
>  anything in a CMD line right? and since it depends on something
>  outside in the net it may be changed or gone later when we rebuild. 
It is going to have to be only things we control. If we rely on random outside 
sources then we can never be guaranteed  the ability to reproduce.
 
>  > > 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.
>  
>  Sure. I think seperate would be ok. 
Seperaste is okay,  but I think we should
enable people who are one to easily 
be the other. 
 
>  > > 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.
>  
>  Fedora Infrastructure has a admin user that can create components and
>  such under the "Fedora" Product. So, just a infrastructure ticket would
>  be the way to go. 
I personally would rather see us start day 1 with some kind of
review app 
rather than bugzilla, something that could grow to incorporate rpms down the 
road. I really think that bugzilla is clunky for review processes.

Dennis