4 ms·

Speaking for the DevOps, a large part of the job is being responsible for building trusted systems from trusted components. I want to continue considering Docke

by 23david 12y ago

Speaking for the DevOps, a large part of the job is being responsible for building trusted systems from trusted components. I want to continue considering Docker to be part of that trusted stack, but from looking at the minutes, it seems that you are willing to mislead even large partners like Google while on the record. JB (Google): Docker is an anchor of a large ecosystem of projects. Docker Inc bought Fig, is it a separate project or is it going to be in Docker? SH: it should be explicit. The Fig guys make proposals and those are reviewed as every body else's. JB (Google): The idea is we will be more comfortable if we know how to contribute both to Docker and the larger ecosystem. SH: The day after Docker Inc. acquired Fig nothing changed at all, everything is still in the Open. The reason for the acquisition was to make Docker more user friendly. The experience should be awesome. The more people we can throw at the problem the better. VL: Understanding what is off limits or at least where the limits are would be helpful. This is entirely driven by technology? We can collaborate "here" but maybe we can compete "there". BG: It's absolutely right, there is a large number of projects competing with Docker Inc. and that's fine. Some folks want Docker to remain a packaging format. We should add a statement there on clarifying this. Source (both as github gist and google doc): https://gist.github.com/inthecloud247/00eb3130f728b635db9e https://docs.google.com/document/d/1JfWNzfwptsMgSx82QyWH_Aj0DRKyZKxYQ1aursxNorg Just today, the "Host management" proposal initiated by a Fig developer was closed (by him) without any discussion after he released the new Docker Machine project (which AFAIK was initiated without any public discussion or warning.) https://github.com/docker/docker/issues/8681 https://github.com/docker/docker/issues/8681

smt88 12y ago
I definitely haven't scrutinized this as much as you have, but I don't see the scandal here. Docker Machine is separate from Docker. Once Machine was released, what was the point of talking about integrating the functionality into Docker? They've repeatedly stated that they want Machine and Swarm to be totally separate tools.
choppaface 12y ago
Joe Beda is just trying to reduce the amount of work and risk his GCE team takes on supporting Docker. Solomon is re-asserting the Docker project's autonomy. There's no scandal here. Tension, yes, but Joe Beda is playing textbook strategies in the interest of Google's business model, and Solomon is giving a mostly textbook response. The Docker team needs some space to execute on the opportunity before them. Space to try, fail, innovate. The end product will be better if they have that space and don't have to achieve equilibrium with too many stakeholders or worry about political microfriction when attempting big leaps. The bleeding edge is bloody; if you need full-featured orchestration TODAY, your best bet is probably something older than Swarm, Fig, etc.
yazaddaruvala 12y ago
A container, while it can be many processes, in the case of Docker is just one process. So its just a better Operating System process... Why then is there all this fuss about how these projects are organized? If its a good idea (which it is) won't Linus just reimplement(conform) all of these projects and move them into the kernel anyways?
- vidarh 12y ago
  > in the case of Docker is just one process. That is not true. It can be just one process. It does not have to be. > So its just a better Operating System process No. That's just a tiny bit of what Docker provides, and even that part of what Docker provides is largely "packaging" of cgroups functionality. That was largely there with tools like LXC The real value Docker provides is a means of building and managing images, and mediating things like capabilities and port mapping in a user friendly way > won't Linus just reimplement(conform) all of these projects and move them into the kernel anyways? Not a chance. There's no reason why these things needs to be done in kernel space. Some features that they may want, such as improvement to filesystem overlay support, or low level "plumbing" to make overlay networks more efficient, could end up in the kernel if someone comes up with something good, but there'd still be plenty to do for the userspace tools.

by 23david 12y ago

smt88 12y ago

I definitely haven't scrutinized this as much as you have, but I don't see the scandal here. Docker Machine is separate from Docker. Once Machine was released, what was the point of talking about integrating the functionality into Docker? They've repeatedly stated that they want Machine and Swarm to be totally separate tools.

choppaface 12y ago

Joe Beda is just trying to reduce the amount of work and risk his GCE team takes on supporting Docker. Solomon is re-asserting the Docker project's autonomy. There's no scandal here. Tension, yes, but Joe Beda is playing textbook strategies in the interest of Google's business model, and Solomon is giving a mostly textbook response. The Docker team needs some space to execute on the opportunity before them. Space to try, fail, innovate. The end product will be better if they have that space and don't have to achieve equilibrium with too many stakeholders or worry about political microfriction when attempting big leaps. The bleeding edge is bloody; if you need full-featured orchestration TODAY, your best bet is probably something older than Swarm, Fig, etc.

yazaddaruvala 12y ago

A container, while it can be many processes, in the case of Docker is just one process. So its just a better Operating System process... Why then is there all this fuss about how these projects are organized? If its a good idea (which it is) won't Linus just reimplement(conform) all of these projects and move them into the kernel anyways?

vidarh 12y ago
> in the case of Docker is just one process. That is not true. It can be just one process. It does not have to be. > So its just a better Operating System process No. That's just a tiny bit of what Docker provides, and even that part of what Docker provides is largely "packaging" of cgroups functionality. That was largely there with tools like LXC The real value Docker provides is a means of building and managing images, and mediating things like capabilities and port mapping in a user friendly way > won't Linus just reimplement(conform) all of these projects and move them into the kernel anyways? Not a chance. There's no reason why these things needs to be done in kernel space. Some features that they may want, such as improvement to filesystem overlay support, or low level "plumbing" to make overlay networks more efficient, could end up in the kernel if someone comes up with something good, but there'd still be plenty to do for the userspace tools.