[predakanga]

The issue that I have with the newly imagined Docker Swarm is that it continues Docker's trend of trying to be a jack of all trades.

I have no specific examples for Docker Swarm, but using this approach in other areas has led to some pretty major deficiencies in Docker's design that they have been slow to fix, and I'm not keen on seeing that happen again.

For a concrete example, see https://github.com/docker/docker/issues/19474 - in a minor release, they completely changed how DNS worked and broke previously working systems (i.e. https://github.com/weaveworks/weave/issues/2157), all in the name of service discovery

[zebra9978]

I see.

incidentally the embedded DNS feature is fairly extensively leveraged by kubernetes - it takes of the situations where you dont want to muck around with underlying /etc/hosts (on the actual metal) and do your changes only on the containers.

But I'm hearing what you are saying more and more - Docker Inc is having a huge PR problem. Docker Swarm may actually be good, but people are generally disliking the organization itself.

You dont see these kind of answers with Fleet, Mesos..even Openstack. Docker Swarm is a genuinely sweet piece of tech.. so this is rather unfortunate.

[mentat]

They have a PR problem because they break interfaces in minor releases and have actively pushed back on criticism for doing so as "they need to be agile" and "can't be boxed in by competitors".

[vidarh]

My biggest issue with swarm is when you have clusters that also needs scheduling of non-Docker workloads.