On Tue, May 3, 2016 at 12:32 PM, Kevin Fenzi <kevin@xxxxxxxxx> wrote: > On Tue, 3 May 2016 11:22:30 -0500 > Adam Miller <maxamillion@xxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx > http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx > -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
