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_with_C... [3] - https://fedoraproject.org/wiki/Draft/Packaging:DockerLayeredImageNamingGuide... [4] - https://fedorahosted.org/fesco/ticket/1573
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 leastin 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_with_C... [3] - https://fedoraproject.org/wiki/Draft/Packaging:DockerLayeredImageNamingGuide... [4] - https://fedorahosted.org/fesco/ticket/1573 -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
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.
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/devel@lists.fedoraproject.org/...
On Fri, Apr 29, 2016 at 7:55 AM, Colin Walters walters@verbum.org 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@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
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
On Sun, May 1, 2016 at 10:26 AM, Subhendu Ghosh sghosh151@gmail.com 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@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
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.
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?
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).
On Thu, 28 Apr 2016 17:52:44 -0500 Adam Miller maxamillion@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 counterpartat 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
On Mon, May 2, 2016 at 12:07 PM, Kevin Fenzi kevin@scrye.com wrote:
On Thu, 28 Apr 2016 17:52:44 -0500 Adam Miller maxamillion@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 counterpartat 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
On Tue, 3 May 2016 11:22:30 -0500 Adam Miller maxamillion@fedoraproject.org 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
On Tue, May 3, 2016 at 1:32 PM, Kevin Fenzi kevin@scrye.com wrote:
On Tue, 3 May 2016 11:22:30 -0500 Adam Miller maxamillion@fedoraproject.org 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
On Tue, May 3, 2016 at 12:32 PM, Kevin Fenzi kevin@scrye.com wrote:
On Tue, 3 May 2016 11:22:30 -0500 Adam Miller maxamillion@fedoraproject.org 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@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
On 4 May 2016 at 21:48, Adam Miller maxamillion@fedoraproject.org wrote:
On Tue, May 3, 2016 at 12:32 PM, Kevin Fenzi kevin@scrye.com wrote:
On Tue, 3 May 2016 11:22:30 -0500 Adam Miller maxamillion@fedoraproject.org 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.
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@fedoraproject.org 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
-
Adam Miller -
Colin Walters -
Daniel J Walsh -
Dennis Gilmore -
James Hogarth -
Josh Boyer -
Kevin Fenzi -
Matthew Miller -
Ralph Bean -
Subhendu Ghosh