It's the danger of running against "latest" all the time...But it's been a day of chasing my own tail when creating a new cluster (Mesos, but that really isn't an issue) and using some tools built against the prior version (volume manager plugin, etc.) that break with updates to Docker.
It seems like if one piece gets an upgrade, every moving component relying on some APIs may need to be looked at as well.
Did a PR on one issue.
Currently chasing my tail to see if a third party lib is out of whack with the new version or it's something I did.
The whole area is evolving and the cross pollination of frameworks, solutions (weave, etc), make for a complicated ecosystem. Most people don't stay "Docker only". I'm curious to see the warts that pop up.
I'm also running Mesos and Docker as a containerizer, and experienced the same problems (i.e. API change on the Docker volumes leads to broken volume driver implementations).
Even within the Mesos environment, there are so many nuts and bolts which have to fit together that sometimes I'm just fed up with the complexity. Furthermore, releases of Mesos and Marathon are not necessarily synched... Stateful apps? No go... Persistent volumes in Marathon? Maybe in v0.16... Graceful shutdown of Docker containers? No go...
It seems like if one piece gets an upgrade, every moving component relying on some APIs may need to be looked at as well.
Did a PR on one issue.
Currently chasing my tail to see if a third party lib is out of whack with the new version or it's something I did.
The whole area is evolving and the cross pollination of frameworks, solutions (weave, etc), make for a complicated ecosystem. Most people don't stay "Docker only". I'm curious to see the warts that pop up.