4 ms·

These aren't new projects... just rebranded versions of half-baked feature proposals that I thought were still being reviewed/discussed. I guess somewhere a dec

by 23david 12y ago

These aren't new projects... just rebranded versions of half-baked feature proposals that I thought were still being reviewed/discussed. I guess somewhere a decision was made to move forward regardless of community concerns? Baking these features into Docker is the beginning of the end of Docker's Enterprise story. Moving forward with these proposals guarantees the rise of Rocket and other Enterprise focused containers. Docker is forking its own community here.

bfirsh 12y ago
Both Machine and Swarm are not baked into Docker – they are separate projects and binaries: https://github.com/docker/machine https://github.com/docker/machine https://github.com/docker/swarm https://github.com/docker/swarm Compose is still in the design proposal stage. We want to hear whether you think it should be built into Docker or not: https://github.com/docker/docker/issues/9459 https://github.com/docker/docker/issues/9459
- 23david 12y ago
  Docker Machine looks to be a revision/rebrand of your docker hosts proposal made in the last 1-2 days or so. Very confusing. The proposal discussion: https://github.com/docker/docker/issues/8681 https://github.com/docker/docker/issues/8681 Rename "docker hosts" to "docker machines": https://github.com/bfirsh/docker/commit/e6abec4033f48d1cad31380f3c94da137b64ae74 https://github.com/bfirsh/docker/commit/e6abec4033f48d1cad31... 2 days ago, from you: I have now rebased the host management branch on top of #8265 and squashed it: https://github.com/bfirsh/docker/compare/host-management Any pull requests should now be based on top of that. The driver interface hasn't changed, so it should be a trivial matter to rebase any existing pull requests. The main thing which has changed is that drivers are expected to set up identity auth for communication with the host. See this commit for an example of how to do so. The old branch is here for reference. Full update and preview builds coming soon." 1 day ago, a message from tianon, core Docker maintainer: Has there been any progress on splitting the actual driver implementations out of the core binary? And now this. Color me confused.
  - mynameisvlad 12y ago
    The proposal was made in October, no? The only thing that happened 2 days ago was renaming it to "docker machines". So unless I misread the thread, your timeline is a bit off.
- deniszgonjanin 12y ago
  As a heavy fig user, it seems compose is really just fig, but rewritten in Go and merged into Docker. It should be kept as a separate project, if modularity and a 'tight core' really is the long term plan for the future of Docker.
ABS 12y ago
I'm at DockerCon and nothing that was shown is baked into Docker. These are all separate projects that use the standard docker APIs like every other tool does/can. In fact they announced a partnership with Mesosphere that will swap Swarm out and replace it with Mesos as an example.
- 23david 12y ago
  If it's an open/pluggable system why the need for these 'partnerships'? Any OSS project can just quickly hack in support for Docker, just as they've been doing for almost 2 years now. This is getting ridiculous.
  - tracker1 12y ago
    Easy answer to the partnerships... Money to pay their employees... and influence from the partners on the future development of the project.
    - nickstinemates 12y ago
      (disclaimer: I run technology / alliance partnerships for Docker) 1) Money is definitely not the case - docker is well capitalized. A special benefit of being in that situation is you don't have to do unnatural things like partner for money. 2) We welcome contributions from everyone, partners or not. Influence is gained by real contribution. The reason we build partnerships is to ensure a few main things #1 (and the biggest) Docker is made available on a wide variety of platforms, allowing developers and admins to work in native environments instead of fork-lifting to another just to try it out. #2 Enable a network of services, products, systems integrator, IT vendors, etc. to have support, training, and other necessary things as they offer docker features in their products. This allows those who do not make containers and container services the core of their business, and instead focus on making/solving different problems. I am more than happy to walk you or anyone else through partner strategy at any time. I'm easy to find.
      - 23david 12y ago
cpuguy83 12y ago
These are completely separate projects, not baked into Docker. github.com/docker/machine github.com/docker/swarm

by 23david 12y ago

bfirsh 12y ago

Both Machine and Swarm are not baked into Docker – they are separate projects and binaries: https://github.com/docker/machine https://github.com/docker/machine https://github.com/docker/swarm https://github.com/docker/swarm Compose is still in the design proposal stage. We want to hear whether you think it should be built into Docker or not: https://github.com/docker/docker/issues/9459 https://github.com/docker/docker/issues/9459

23david 12y ago
Docker Machine looks to be a revision/rebrand of your docker hosts proposal made in the last 1-2 days or so. Very confusing. The proposal discussion: https://github.com/docker/docker/issues/8681 https://github.com/docker/docker/issues/8681 Rename "docker hosts" to "docker machines": https://github.com/bfirsh/docker/commit/e6abec4033f48d1cad31380f3c94da137b64ae74 https://github.com/bfirsh/docker/commit/e6abec4033f48d1cad31... 2 days ago, from you: I have now rebased the host management branch on top of #8265 and squashed it: https://github.com/bfirsh/docker/compare/host-management Any pull requests should now be based on top of that. The driver interface hasn't changed, so it should be a trivial matter to rebase any existing pull requests. The main thing which has changed is that drivers are expected to set up identity auth for communication with the host. See this commit for an example of how to do so. The old branch is here for reference. Full update and preview builds coming soon." 1 day ago, a message from tianon, core Docker maintainer: Has there been any progress on splitting the actual driver implementations out of the core binary? And now this. Color me confused.
- mynameisvlad 12y ago
  The proposal was made in October, no? The only thing that happened 2 days ago was renaming it to "docker machines". So unless I misread the thread, your timeline is a bit off.
deniszgonjanin 12y ago
As a heavy fig user, it seems compose is really just fig, but rewritten in Go and merged into Docker. It should be kept as a separate project, if modularity and a 'tight core' really is the long term plan for the future of Docker.

ABS 12y ago

I'm at DockerCon and nothing that was shown is baked into Docker. These are all separate projects that use the standard docker APIs like every other tool does/can. In fact they announced a partnership with Mesosphere that will swap Swarm out and replace it with Mesos as an example.

23david 12y ago
If it's an open/pluggable system why the need for these 'partnerships'? Any OSS project can just quickly hack in support for Docker, just as they've been doing for almost 2 years now. This is getting ridiculous.
- tracker1 12y ago
  Easy answer to the partnerships... Money to pay their employees... and influence from the partners on the future development of the project.
  - nickstinemates 12y ago
    (disclaimer: I run technology / alliance partnerships for Docker) 1) Money is definitely not the case - docker is well capitalized. A special benefit of being in that situation is you don't have to do unnatural things like partner for money. 2) We welcome contributions from everyone, partners or not. Influence is gained by real contribution. The reason we build partnerships is to ensure a few main things #1 (and the biggest) Docker is made available on a wide variety of platforms, allowing developers and admins to work in native environments instead of fork-lifting to another just to try it out. #2 Enable a network of services, products, systems integrator, IT vendors, etc. to have support, training, and other necessary things as they offer docker features in their products. This allows those who do not make containers and container services the core of their business, and instead focus on making/solving different problems. I am more than happy to walk you or anyone else through partner strategy at any time. I'm easy to find.
    - 23david 12y ago

cpuguy83 12y ago

These are completely separate projects, not baked into Docker. github.com/docker/machine github.com/docker/swarm