Hi all, Docker announced language stacks images in Docker Hub last week: http://blog.docker.com/2014/09/docker-hub-official-repos-announcing-langu... They are all based on Debian and pretty outdated. We should consider creation of such images for our stacks based on Fedora - we are thinking of releasing F21 Alpha base image so we could maybe build them on top of it. As we still don't have a build service I proposed some time ago, we could use Docker Automated Builds - we would "just" need to prepare Dockerfiles. Have a look at what they provide and let me know if you think it's interesting for us. Thanks, Vašek

On 09/30/2014 01:28 AM, Marcela Mašláňová wrote: > Cool, we should do it better. From what I see every image contains just > the main package downloaded from upstream. If those users are using > cpan/pypi/npm, there's not much added value. > I wouldn't say they are outdated at all. They are missing just released > node.js 0.12 and quite fresh Ruby 2.2 (from interpreted languages). > > Do you have vision what should be done? (Like package in dockerfile at > least what we provide for RSHCL). Otherwise, we could create dockerfile > for every existing framework, but we probably don't want to go this way > and support all existing combinations. Too much maintenance. > It might be good to use combinations, which we are providing in > DevAssistant or pick one supported frameworks for every language, but > someone has to pick the One... I think this combinatorial explosion problem is why offering a lot of prebuilt images is the wrong way to go with this. The desire to do so is a reflection of the fact that the tooling for building and managing Docker images is still relatively immature - I don't know exactly when Koji was written, but I'd suggest that the current state of Docker image management is, at best, where the RPM build process would have been pre-Koji. Instead of offering a wide array of prebuilt images, I think OpenShift Origin are going in the right direction with v3, taking full advantage of the notion of composable layers in the design of Docker: https://openshift.github.io/documentation/openshift-pep-010-docker-cartri... I don't think that's something we want to reinvent independently at the Fedora layer - instead, I'd encourage folks interested in the concept of a "Docker build service" to get involved with OpenShift Origin v3, and ensure that it's at least possible to get the built images *out* for direct deployment with Docker, rather than *only* allow them to be deployed into the OpenShift instance. Ideally, the image build service and image registry components would be independently deployable, without a full OpenShift instance around them. Either way though, the OpenShift Origin project has a relatively high concentration of Docker expertise at this point, and also a pressing need for an image build service as part of the v3 redesign, so it's likely a good direction to explore. Regards, Nick.

But what I see as a problem at the moment is that Fedora is not well recognized in Docker land. Red Hat as well as Cent OS are, but I don't see Fedora mentioned anywhere.

But I agree with Marcela that it wouldn't be easy at all to provide and maintain layered images which are useful for developers.

But what I see as a problem at the moment is that Fedora is not well recognized in Docker land. Red Hat as well as Cent OS are, but I don't see Fedora mentioned anywhere.

On Tue, Sep 30, 2014 at 12:45:52PM +1000, Nick Coghlan wrote: > I think this combinatorial explosion problem is why offering a lot of > prebuilt images is the wrong way to go with this. The desire to do so is > a reflection of the fact that the tooling for building and managing > Docker images is still relatively immature - I don't know exactly when > Koji was written, but I'd suggest that the current state of Docker image > management is, at best, where the RPM build process would have been > pre-Koji. > > Instead of offering a wide array of prebuilt images, I think OpenShift > Origin are going in the right direction with v3, taking full advantage > of the notion of composable layers in the design of Docker: > https://openshift.github.io/documentation/openshift-pep-010-docker-cartri... I agree that this is totally the way to go eventually and as soon as possible. However, I also think that we should cover the image approach in the meantime, and possibly some of the basics will always be useful.

On Oct 7, 2014, at 4:32 AM, Václav Pavlín <vpavlin(a)redhat.com&gt; wrote: Hi Clayton, We were discussing Language Stacks announcement for Docker Hub on our last meeting and I'd like you to join our discussion as we find OpenShift useful source of information about developers. We as Env&Stacks WG would like to provide reasonable Docker layered images to Fedora users which they could use for development and deployment of their applications. OpenShift could probably provide some hints for this - which languages and stacks OpenShift developers use most and how do they use them? You will be welcome to join our meeting at #fedora-meeting (Tue, 9am EDT). Regards, Vašek > On 2.10.2014 08:42, Nick Coghlan wrote: >> On 10/01/2014 08:39 AM, Matthew Miller wrote: >>> On Tue, Sep 30, 2014 at 12:45:52PM +1000, Nick Coghlan wrote: >>> I think this combinatorial explosion problem is why offering a lot of >>> prebuilt images is the wrong way to go with this. The desire to do so is >>> a reflection of the fact that the tooling for building and managing >>> Docker images is still relatively immature - I don't know exactly when >>> Koji was written, but I'd suggest that the current state of Docker image >>> management is, at best, where the RPM build process would have been >>> pre-Koji. >>> >>> Instead of offering a wide array of prebuilt images, I think OpenShift >>> Origin are going in the right direction with v3, taking full advantage >>> of the notion of composable layers in the design of Docker: >>> https://openshift.github.io/documentation/openshift-pep-010-docker-cartri... >> >> I agree that this is totally the way to go eventually and as soon as >> possible. However, I also think that we should cover the image approach in >> the meantime, and possibly some of the basics will always be useful. > Aye, Vaclav and Marcela persuaded me I was wrong at this week's WG > meeting - there's likely something simpler we can do in the meantime, > even if it has scalability issues. > > Cheers, > Nick. -- Lead Infrastructure Engineer Developer Experience Brno, Czech Republic

> As we still don't have a build service I proposed some time ago, we > could use Docker Automated Builds - we would "just" need to prepare > Dockerfiles. Take a look at https://github.com/fedora-cloud/Fedora-Dockerfiles — adding to that might be the way to go, or else providing a companion.

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

So, what I don't get about these Dockerfiles... Why do so many of them use supervisord? IIUC supervisord is sort of a replacement for systemd. I know there have been some issues with systemd and containers and that there were efforts to make systemd work in containers, so I assume these Dockerfiles will switch to systemd once it is ready, is that correct?