From the Rocket announcement:
simple and open specifications for a portable container format...
fill the gap for companies that just want a way to securely and
portably run a container
these vendors want to create orchestration solution (sic) that are
tailored for their particular infrastructure or offerings, and do
not welcome the notion of portability
Rocket looks very cool, and while it certainly does prevent some of the issues with docker security, it misses some of the benefits... like a remote API as there isn't a rktd, and many people will undoubtedly write them. So in that regard, I'd have to say rocket offers less openness.
With the current docker design, I see no reason why libcontainer couldn't add a rocket or lxd backend and be done with it however. As a sysadmin/developer to builds things, I see this as healthy for the container ecosystem even if it does certainly come off as a bit uncool from @phillips and the coreos crew. I'm kind of biased in that I think the only good multi-host docker / container manager will ultimately be mesos with kubernetes ontop.
I don't see why they need to view this as an opportunity to fight back and criticize another app container system, rather than enthusiasm about the continued spread of containers and expressing a desire to cooperate on building open, interoperable standards.
No, I'm not a Docker fanboy. Yes, I think Docker is pretty cool. Yes, I think the competition from Rocket is great and I can't wait to see how things go.
CoreOS is building a container runtime, Rocket https://coreos.com/blog/rocket/ https://news.ycombinator.com/item?id=8682525
(This appears to be a case where the writer is so immersed in their own world, they forget readers might not be as up to speed as their own colleagues.)
A small number of vendors disagree with this direction. Some have expressed their concern that, as
Docker expands its scope, there may be less room for them to create differentiated, value-added
offerings. In some cases, these vendors want to create orchestration solution that are tailored for their
particular infrastructure or offerings, and do not welcome the notion of portability. In some cases, of
course, there are technical or philosophical differences. We hope to address some of the technical
arguments posed by the Rocket project in a subsequent post.Let's hope they mean it.
> While we disagree with some of the arguments and questionable rhetoric and timing of the Rocket announcement, we hope that we can all continue to be guided by what is best for users and developers.
Interesting way to end their reply to the announcement of Rocket. The whole post reads like a typical PR response without real arguments. I'm looking forward to their followup post.
Despite their arguments being valid or not, I cannot help but hearing this message over and over in my head.
What's he talking about regarding the timing of the announcement?
From a security and composability perspective, the Docker
process model - where everything runs through a central
daemon - is fundamentally flawed. To “fix” Docker would
essentially mean a rewrite of the project, while inheriting
all the baggage of the existing implementation.That said, I like this announcement. Docker was focusing on becoming an App store. I like that Rocket brings the focus back to technology.
Does anyone care to explain what's suspicious about the timing?
Yes please, that's my preferred format.