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.