Quick preface: I know I keep crapping on some parts of your ideas here, but I would to reiterate the core idea is absolutely great - easy-to-use images based around s6. Letting the user quickly prototype a service by just running `docker run imagename command some arguments` is actually a *great* idea, since that lets people start making images without needing to know a lot of details about the underlying process supervisor. It's flexible, I know a lot of people like to initially try things "on-the-fly" before sitting down to write a Dockerfile, and this allows for that.
You're just getting caught up in some of the finer implementation details, like the usage of ENTRYPOINT vs CMD vs environment variables and so on, how to handle dealing with shell arguments, these parts are solved problems. So, onwards: > * Convert Gorak's current "/init" script from bash --> execline > * Testing on Gorak's ubuntu base image > > * Add support for spawning the argv[], for cmd and entry point. > * Testing on Gorak's ubuntu base image > > * Create new base image for Alpine (thanks for mentioning it earlier John) > * Possibly create other base image(s). e.g. debian, arch, busy box and so on. > * Test them, refine them. Everything up to here sounds fine and dandy - make some images and get them out there, I'm all about that. > > * Document the new set of s6 base images > * Blog about them Also awesome. > * Inform the fusion people we have created a successor Hmm, I don't think that'll go over well, nor do I think it's really an appropriate thing to do. Some people like the phusion images, for one. The whole reason they exist is because a lot of guys keep trying to use Docker as VM, and get upset when they can't SSH into the container. I don't see these as a "successor", rather an "alternative." Besides, none of us would even be concerned about this if Phusion hadn't made something in the first place! > * Inform 1(+) member(s) of Docker Inc to make them aware of new s6-images. Docker Inc isn't *that* concerned about what types of images are being made. They'd probably get that email and say "..alright cool?" The right approach (in my opinion) is to just build a really cool product, then let the product speak for itself. > Of course the proper channel ATM is to open issues and PR's on Gorak's > current s6-ubuntu base image. So we can open those fairly soon and > move discussion to there. It might be worth starting up a github organization or something and creating new images under that namespace. I can't speak for Gorak, but the proposed image is sufficiently different enough from my existing one that I'd have to make a new image anyways. My existing ones don't allow for that `docker run imagename command arguments` use-case, for me this constitutes a breaking change. I'd rather just deprecate my existing ones, and either join in on Gorak's project, or start a new one, either way. > > > Another thing we don't need to worry about right now (but may become a > consideration later on): > > * Once there are 2+ similar s6 images. > * May be worth to consult Docker Inc employees about official / base > image builds on the hub. > * May be worth to consult base image writers (of the base images we > are using) e.g. 'ubuntu' etc. I wouldn't ever really worry about that. The base images don't have any kind of process supervisor, and they shouldn't. They're meant to be minimal installs for building stuff off of. > > * Is a possibile to convert to github organisation to house multiple images > * Can be helpful for others to grow support and other to come on > board later on who add new distros. > * May be worth to ensure uniform behaviour of common s6 components > across different disto's s6 base images. > * e.g. Central place of structured and consistent documentation > that covers all similar s6 base images together. Yep, see my comments above. I'm all about that. > > Again I'm not mandating that we need to do any of those things at all. > As it should not be anything of my decision whatsoever. But good idea > to keep those possibilities in mind when doing near-term work. "Try to > keep it general" basically. > > For example: > > I see a lot of good ideas in Gorak's base image about fixing APT. It > maybe that some of those great ideas can be fed back upstream to the > official ubuntu base image itself. Then (if they are receptive > upstream) it can later be removed from Gorak's s6-specific ubuntu base > image (being a child of that). Which generally improves the level > standardization, granularity (when people choose decide s6 or not), > etc. They probably won't be that receptive - Gorak isn't changing the base Ubuntu image *drastically*, but it still deviates from how a normal, plain-jane Ubuntu install works. The base images should be as close to stock as possible, since that's what most people will be coming from. If the base Ubuntu image does something differently from an actual base Ubuntu install, it's a broken image. -John