5 ms·

This is a great question. CoreOS is currently working on adding support for Rocket[0] to Kubernetes. There is still a lot of work to do here, but things are pr

This is a great question. CoreOS is currently working on adding support for Rocket[0] to Kubernetes. There is still a lot of work to do here, but things are progressing nicely. Kubernetes is a true opensource project and accepts contributions that makes sense. Supporting another container runtime engine makes sense in terms of choice for the community and forces clean separation between Kubernetes, the cluster manager, and the underlying container runtime engine. When it comes to Rocket vs Docker I think the competition will be good for both projects and the community as a whole. At the end of the day, both projects and the communities behind them want people to be successful with containers. [0] https://github.com/GoogleCloudPlatform/kubernetes/pull/5518 https://github.com/GoogleCloudPlatform/kubernetes/pull/5518

Alupis 12y ago
> both projects and the communities behind them want people to be successful with containers. I think it's better said, Docker wants people to be successful with containers, so long as it's Docker containers.[1][2][3] We've seen a lot of very open work coming from the CoreOS team with Rocket and the ACI... unfortunately we've only seen negativity and mud slinging coming from the other camp.[2][4][5][6][7] Docker is more interested in having an "open" implementation, rather than an open specification. The things is... an Open Specification is far more important for industry changing technology like containers. [1] https://news.ycombinator.com/item?id=8683705 https://news.ycombinator.com/item?id=8683705 [2] https://news.ycombinator.com/item?id=8938409 https://news.ycombinator.com/item?id=8938409 [3] https://news.ycombinator.com/item?id=8789181 https://news.ycombinator.com/item?id=8789181 [4] https://news.ycombinator.com/item?id=8938066 https://news.ycombinator.com/item?id=8938066 [5] https://news.ycombinator.com/item?id=8938176 https://news.ycombinator.com/item?id=8938176 [6] https://github.com/docker/docker/issues/10643 https://github.com/docker/docker/issues/10643 [7] https://github.com/docker/docker/issues/9538 https://github.com/docker/docker/issues/9538
- curun1r 12y ago
  Don't kid yourself...it's been negative on both sides. CoreOS called Docker fundamentally flawed, though they've backed away from that a bit. From what I can tell, CoreOS was happy to let Docker, Inc control the container platform and build orchestration tools on top of Docker, since it's pretty clear that no one is willing to pay for the base containerization layer and the only money to be made is in orchestration. But then Docker released their own orchestration strategy and that started the current period we're in where both companies have come off as being very unprofessional and concerned only with their own future success. Between Docker trying to build almost everything into the actual Docker executable (it's a container runner, API server, build tool, process monitor, cloud provisioner and orchestration tool...those last two are only not the case because they got called on the strategy) and CoreOS's pointless pushing of rkt (rkt itself isn't pointless, but the PR to add rkt support to Docker was, as was implementing Docker support in rkt). Both sides have foolishly put their own interests ahead of the container ecosystem. To say that either of the two companies has been the bad actor in all the drama would be biased. They've both come across like spoiled little children trying to get their way. As someone who has been pushing my company (~8000 employees) to consider implementing a containerized deployment strategy, it's been hugely inconvenient to have to concede to people arguing against containerization all the points around how unprofessional the companies in the space have been, both in behavior and coding practices.
  - fredkelly 12y ago
    +1, This has been my interpretation too, I feel like a lot of the rkt PR was subtly aimed at Docker, it was very much "this is why it's better" rather than "this is why it's good".
    - politician 12y ago
      Honestly, as a consumer of both projects, I'm happy that rkt exists because it provides a working demonstration of a solution where container images are orthogonal to other concepts such as orchestration. If it went the other way, our vendors would be swearing up and down that the only way for this container thing to work is if we install their complete solution. I love my Apple MacBook Pro and its soldered components, but I need my data center to be meaningfully upgradable.
      - ecnahc515 12y ago
        I love Docker, but it feels a lot like the days of incompatible VM images, where you got super locked in, and if you tried anything that wasn't what they had designed for, then you got screwed.
  - Alupis 12y ago
    Can you point to specific examples of the CoreOS team dealing low blows? Frankly, CoreOS started the ACI and Rocket because there was no open specification. Docker had started off with somewhat of a specification, then deleted it. A year later, CoreOS launches ACI as a public open spec, and suddenly Docker whips one of their own up over a weekend. The entire point of ACI is nobody owns the specification. Docker wants to own the spec, govern the spec, and be the spec. With something as critical as this technology -- we need an open specification -- far more than an open implementation.
    - curun1r 12y ago
      The three examples in my first post, combined with their timing in releasing Rocket. Their initial press release was filled with vitriolic rhetoric...so much so that they had to recant most of it. And coming so soon after Docker started talking about their orchestration plans, it's pretty transparent that CoreOS doesn't feel that the community needs and open specification. They feel that CoreOS needs an open specification to prevent Docker, Inc from leveraging the common implementation to gain an unfair advantage in the Docker orchestration market. After announcing Rocket, they embarked on a campaign of subtly trying to show people how uncooperative Docker, Inc was being, first by implementing Docker support in Rocket and then that sham of PR (the first ever PR PR) where they implemented Rocket support in Docker. It was so much code and, with no warning that it was coming, there was no chance that it would ever get merged. The only point of that was to try to argue that they'll support Docker and Docker won't support Rocket. It's so transparently passive aggressive to anyone that understands the underlying dynamic expressed in my earlier post. > With something as critical as this technology -- we need an open specification That's fine. But there's a right way and a wrong way to get there. They should have started by documenting the existing Docker implementation. It's open source and implemented by many Docker partners (Amazon, Google, etc). Once the community has accepted the specification, as the authors, they would have license to go to the community and push for changes they feel are necessary. Docker isn't fundamentally flawed, but it is flawed and I think even Docker, Inc admits that. There are changes that are necessary and they need to happen out in the open rather than behind closed doors at Docker, Inc. Starting their own format was an attempted power move designed to fracture the community. And I see it as largely having failed. There are a lot of things that I like better about Rocket, but the ecosystem around it is way too nascent to even consider using it. There's no collection of images that I, as a developer, can leverage to avoid building everything from scratch. Docker Hub is a big part of the reason to use Docker. And there's no third-party integrations for Rocket. I can use Docker through AWS ECS and have the piece of mind to know that I can migrate to GCE and my Docker images will basically just work. With Rocket, I basically have to use CoreOS (a design I'm not thrilled with) or roll my own. If either company seemed like it was trying to put the community first, I'd be 100% behind that company. But CoreOS's rhetoric around trying to position themselves that way is simply indicative of them not having first-mover advantage. Both companies need to grow up and realize that this is a nascent market and there is room for both to succeed if they're only willing to cooperate. But if they continue to squabble like little children fighting over a ball, the parents are going to take that ball away. Google and Amazon will roll their own proprietary containerization or, worse yet (for Docker and CoreOS), they'll cooperate on an open standard. But the community is what's important. If they can continue to grow the community, profits will follow. If they continue to try to corner the market and push each other out, the community will go elsewhere and both companies will fail.

Alupis 12y ago

> both projects and the communities behind them want people to be successful with containers. I think it's better said, Docker wants people to be successful with containers, so long as it's Docker containers.[1][2][3] We've seen a lot of very open work coming from the CoreOS team with Rocket and the ACI... unfortunately we've only seen negativity and mud slinging coming from the other camp.[2][4][5][6][7] Docker is more interested in having an "open" implementation, rather than an open specification. The things is... an Open Specification is far more important for industry changing technology like containers. [1] https://news.ycombinator.com/item?id=8683705 https://news.ycombinator.com/item?id=8683705 [2] https://news.ycombinator.com/item?id=8938409 https://news.ycombinator.com/item?id=8938409 [3] https://news.ycombinator.com/item?id=8789181 https://news.ycombinator.com/item?id=8789181 [4] https://news.ycombinator.com/item?id=8938066 https://news.ycombinator.com/item?id=8938066 [5] https://news.ycombinator.com/item?id=8938176 https://news.ycombinator.com/item?id=8938176 [6] https://github.com/docker/docker/issues/10643 https://github.com/docker/docker/issues/10643 [7] https://github.com/docker/docker/issues/9538 https://github.com/docker/docker/issues/9538

curun1r 12y ago
Don't kid yourself...it's been negative on both sides. CoreOS called Docker fundamentally flawed, though they've backed away from that a bit. From what I can tell, CoreOS was happy to let Docker, Inc control the container platform and build orchestration tools on top of Docker, since it's pretty clear that no one is willing to pay for the base containerization layer and the only money to be made is in orchestration. But then Docker released their own orchestration strategy and that started the current period we're in where both companies have come off as being very unprofessional and concerned only with their own future success. Between Docker trying to build almost everything into the actual Docker executable (it's a container runner, API server, build tool, process monitor, cloud provisioner and orchestration tool...those last two are only not the case because they got called on the strategy) and CoreOS's pointless pushing of rkt (rkt itself isn't pointless, but the PR to add rkt support to Docker was, as was implementing Docker support in rkt). Both sides have foolishly put their own interests ahead of the container ecosystem. To say that either of the two companies has been the bad actor in all the drama would be biased. They've both come across like spoiled little children trying to get their way. As someone who has been pushing my company (~8000 employees) to consider implementing a containerized deployment strategy, it's been hugely inconvenient to have to concede to people arguing against containerization all the points around how unprofessional the companies in the space have been, both in behavior and coding practices.
- fredkelly 12y ago
  +1, This has been my interpretation too, I feel like a lot of the rkt PR was subtly aimed at Docker, it was very much "this is why it's better" rather than "this is why it's good".
  - politician 12y ago
    Honestly, as a consumer of both projects, I'm happy that rkt exists because it provides a working demonstration of a solution where container images are orthogonal to other concepts such as orchestration. If it went the other way, our vendors would be swearing up and down that the only way for this container thing to work is if we install their complete solution. I love my Apple MacBook Pro and its soldered components, but I need my data center to be meaningfully upgradable.
    - ecnahc515 12y ago
      I love Docker, but it feels a lot like the days of incompatible VM images, where you got super locked in, and if you tried anything that wasn't what they had designed for, then you got screwed.
- Alupis 12y ago
  Can you point to specific examples of the CoreOS team dealing low blows? Frankly, CoreOS started the ACI and Rocket because there was no open specification. Docker had started off with somewhat of a specification, then deleted it. A year later, CoreOS launches ACI as a public open spec, and suddenly Docker whips one of their own up over a weekend. The entire point of ACI is nobody owns the specification. Docker wants to own the spec, govern the spec, and be the spec. With something as critical as this technology -- we need an open specification -- far more than an open implementation.
  - curun1r 12y ago
    The three examples in my first post, combined with their timing in releasing Rocket. Their initial press release was filled with vitriolic rhetoric...so much so that they had to recant most of it. And coming so soon after Docker started talking about their orchestration plans, it's pretty transparent that CoreOS doesn't feel that the community needs and open specification. They feel that CoreOS needs an open specification to prevent Docker, Inc from leveraging the common implementation to gain an unfair advantage in the Docker orchestration market. After announcing Rocket, they embarked on a campaign of subtly trying to show people how uncooperative Docker, Inc was being, first by implementing Docker support in Rocket and then that sham of PR (the first ever PR PR) where they implemented Rocket support in Docker. It was so much code and, with no warning that it was coming, there was no chance that it would ever get merged. The only point of that was to try to argue that they'll support Docker and Docker won't support Rocket. It's so transparently passive aggressive to anyone that understands the underlying dynamic expressed in my earlier post. > With something as critical as this technology -- we need an open specification That's fine. But there's a right way and a wrong way to get there. They should have started by documenting the existing Docker implementation. It's open source and implemented by many Docker partners (Amazon, Google, etc). Once the community has accepted the specification, as the authors, they would have license to go to the community and push for changes they feel are necessary. Docker isn't fundamentally flawed, but it is flawed and I think even Docker, Inc admits that. There are changes that are necessary and they need to happen out in the open rather than behind closed doors at Docker, Inc. Starting their own format was an attempted power move designed to fracture the community. And I see it as largely having failed. There are a lot of things that I like better about Rocket, but the ecosystem around it is way too nascent to even consider using it. There's no collection of images that I, as a developer, can leverage to avoid building everything from scratch. Docker Hub is a big part of the reason to use Docker. And there's no third-party integrations for Rocket. I can use Docker through AWS ECS and have the piece of mind to know that I can migrate to GCE and my Docker images will basically just work. With Rocket, I basically have to use CoreOS (a design I'm not thrilled with) or roll my own. If either company seemed like it was trying to put the community first, I'd be 100% behind that company. But CoreOS's rhetoric around trying to position themselves that way is simply indicative of them not having first-mover advantage. Both companies need to grow up and realize that this is a nascent market and there is room for both to succeed if they're only willing to cooperate. But if they continue to squabble like little children fighting over a ball, the parents are going to take that ball away. Google and Amazon will roll their own proprietary containerization or, worse yet (for Docker and CoreOS), they'll cooperate on an open standard. But the community is what's important. If they can continue to grow the community, profits will follow. If they continue to try to corner the market and push each other out, the community will go elsewhere and both companies will fail.