Right, Glad that others (maybe Laurent and Gorka) want to do some guys who all have more experience than me with 's6' process supervisor. I way just offering to do it in case, to not impose extra work on anybody who is already busy.
Gorka is now working on something changes today. I don't quite know what those are. It seems like we should check again his repos after he finishes whatever stuff he's currently doing ATM. Fabulous. In respect of recent replies: Laurent, Of course I don't mind any suitable changes upstreamed (that can be upstreamed). And things which are not-docker-specific should not be presented that way (preferable all of them). Providing that the functionality is added and it can be used with docker too amongst other tools. Docker is not the only tool which uses linux namespaces for containerization. And that is the underlying kernel feature (available in all modern linux kernel). I missed saying "try to upstream everything". Sorry - I agree it is a good idea to do that. Just the major requirement I am interested to see fulfilled (one way or another) is a new single tarball build product / build target that combines the 2 or more separate s6 packages into a single tar ball… For the docker ADD mechanism to work. That unified tarball does not need to be named 's6-docker' or anything that is docker-specific. It does not need to be officially sanctioned / provided by upstream or not… Upstream would be better of course but we don't wish to impose our ways upon you! We could also debate what exacty should or should-not be in that single tarball. Or just not bother arguing specifics when there is always the solution to make a 'light' and 'full' variant. With all the optional tools included in the 'full' version. And just the minimum in the 'light'. Where the 'light' appears to be 2 of your current official tarballs. John, Sorry I don't see the point (anymore) of writing s6-specific base images when there is no longer any pressing technical reason to do so. The drawback of choosing that approach is that by publishing some s6 base images, we will always end up neglecting and leaving some out other ones from being supported. Wheras with ADD (from a single tarball source) - that supports all base images in one swoop without any effort whatsoever on our part. And that is a big plus. Of course, once the universal ADD mechanism is working, then it becomes a completely trivial matter to roll new base images that include s6, for whichever distros you wish. With just a single extra line in the Dockerfile. But then it hardly seems worth it telling people to use them rather than ADD, which other users can just do directly themselves? I just get the general impression that most Docker citizens strongly prefer to use official base images whenever possible. Because it is what they know and what they trust. Even if a user writes their own base, they will almost always be FROM: ubuntu or FROM: debian (or 'alpine' now, whichever one they like the most). Meaning that: it is harder to get the general docker population to trust and switch over to some new 's6-*' base image coming from somewhere which is effectively deemed as being a 3rd party repo. If we instead tell them to use the ADD: <tarball_url> method… they will trust it more because they all still get to keep their preferred "FROM: ubuntu" line at the top as always… At least that's my own thought process / reasoning behind such opinion. Where I am coming at from, with this whole 'maybe we should not don't do base images' anymore. On Sat, Feb 28, 2015 at 5:57 PM, John Regan <j...@jrjrtech.com> wrote: > Sweet. And yeah, as Laurent mentioned in the other email, it's the > weekend. Setting dates for this kind of stuff is hard to do, I just > work on this in my free time. It's done when it's done. > > I also agree that s6 is *not* a docker-specific tool, nor should it > be. I'm thankful that Laurent's willing to listen to any ideas we > might have re: s6 development, but like I said, the goal is *not* > "make s6 a docker-specific tool" > > There's still a few high-level decisions to be made, too, before we > really start any work: > > 1. Goals: > * Are we going to make a series of s6 baseimages (like one > based on Ubuntu, another on CentOS, Alpine, and so on)? > * Should we pick a base distro and focus on creating a series of > platform-oriented images, aimed more at developers (ie, a PHP image, a > NodeJS image, etc)? > * Or should be focus on creating a series of service-oriented > images, ie, an image for running GitLab, an image for running an > XMPP server, etc? > > Figuring out the overall, high-level focus early will be really > helpful in the long run. > > Options 2 and 3 are somewhat related - you can't really get to 3 > (create service-oriented images) without getting through 2 (make > platform-oriented images) anyway. > > It's not like a goal would be set in stone, either. If more guys want > to get on board and help, we could alway sit down and re-evaluate. > With more manpower, you could get into doing a whole series of > distro-based, service-oriented images (ie, a Ubuntu XMPP server as > well as an Alpine XMPP server). > > But given we're just a few guys, setting a straightforward small focus > is probably the way to go. I would vote for either creating a series > of baseimages, oriented towards other image-makers, or pick Alpine as > a base, and focus on making small and efficient service-oriented > images (ie, a 10MB XMPP service, something like that) aimed at > sysadmins/users. > > But I'm open to any of those options, or others, so long as it's > within the realm of possibility for just a few people working in their > free time. > > 1. Should be form a GitHub org, and what should it be called? > > I vote yes, I'll go ahead and make it if you want. > > For the org name, I was thinking about starting a series of Alpine > images aimed at users (like I said, 10MB chat service) under the org > name "micro-d" (as in, Micro Docker containers), already. If that's the > focus we go with, then that's probably a pretty OK name. > > If we go with doing a series of simple, easy-to-use baseimages aimed > at other imagemakers, then probably something like "simple-d" (Simple > Docker containers). > > Again, open to suggestions, those are just my initial ideas. The one > thing I would advise against is using s6 in the name, since that > would imply it's a project under the skarnet.org umbrella, which I > don't think this is. It's outside that scope. We can promote how much > we love s6 all we want in the docs, and blog posts, and so on, but > we *shouldn't* do things like call our init "s6-init", name the image > "s6-alpine", stuff like that. > > Once we figure out the high-level goals, we can set out a few more > structural-type things. > > -John