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@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? 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
