3 ms·

There was quite a bit of discussion on this topic in the Docker-dev group. The comment I found the most informative was by the creator of Docker -> https://grou

There was quite a bit of discussion on this topic in the Docker-dev group. The comment I found the most informative was by the creator of Docker -> https://groups.google.com/d/msg/docker-dev/3paGTWD6xyw/xj2XakbfdnoJ https://groups.google.com/d/msg/docker-dev/3paGTWD6xyw/xj2Xa...

mmerickel 12y ago
Yes, I've read all of that. I consider this a blocker for production use of docker and releasing a 1.0 RC without solving this is disconcerting (at least as a process wrapper, it still works fine for wrapping an init system that handles everything itself). Especially since, in that thread, shykes said it will be solved prior to 1.0.
- shykes 12y ago
  You're right, the logging subsystem still needs work before 1.0. We're using the RC label to indicate that we don't plan on breaking APIs and file formats in any major way between now and 1.0, so toolmakers and integrators can start locking down their schedule, and trust that their tools won't be deprecated in a couple months. If it were entirely up to me I would never call it 1.0, because part of me wants it to be flawless before anybody uses it in production. But it's not up to me - a lot of people are already using Docker in production, and there are many organizations already in process of offering commercial support and services for it. Clearly they consider Docker acceptable for their needs at some level - and at some point we'll need to acknowledge that by releasing 1.0, no matter how flawed I find it to be. The improvements won't stop at 1.0 :)
  - mmerickel 12y ago
    That's great to hear - I've dove pretty hard into docker and love it but the logging story has been a dealbreaker for production. Decoupling "create" and "start" has been great when using the Remote API because I can create a container, attach my IO handlers, and then start, removing the need for docker to handle the logs at all (if it supported that). Possibly something like this can be done via the CLI such that docker can just forward the streams into a custom script.

mmerickel 12y ago

Yes, I've read all of that. I consider this a blocker for production use of docker and releasing a 1.0 RC without solving this is disconcerting (at least as a process wrapper, it still works fine for wrapping an init system that handles everything itself). Especially since, in that thread, shykes said it will be solved prior to 1.0.

shykes 12y ago
You're right, the logging subsystem still needs work before 1.0. We're using the RC label to indicate that we don't plan on breaking APIs and file formats in any major way between now and 1.0, so toolmakers and integrators can start locking down their schedule, and trust that their tools won't be deprecated in a couple months. If it were entirely up to me I would never call it 1.0, because part of me wants it to be flawless before anybody uses it in production. But it's not up to me - a lot of people are already using Docker in production, and there are many organizations already in process of offering commercial support and services for it. Clearly they consider Docker acceptable for their needs at some level - and at some point we'll need to acknowledge that by releasing 1.0, no matter how flawed I find it to be. The improvements won't stop at 1.0 :)
- mmerickel 12y ago
  That's great to hear - I've dove pretty hard into docker and love it but the logging story has been a dealbreaker for production. Decoupling "create" and "start" has been great when using the Remote API because I can create a container, attach my IO handlers, and then start, removing the need for docker to handle the logs at all (if it supported that). Possibly something like this can be done via the CLI such that docker can just forward the streams into a custom script.