Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CoreOS is building a container runtime, Rocket

coreos.com

Post reply on HN
Print view View original

141–150 of 295 posts

Re: CoreOS is building a container runtime, Rocket

#141

Post by ridruejo »

Alupis wrote: post #122
lclarkmichalek wrote: post #105

Earlier quoted context omitted.

Might be worth mentioning that you are employed by Docker, if you're going to engage in this discussion.

The Docker team does this a lot, and it's part of their PR machine. They creep their way into and eventually try to steer every conversation regarding containers, especially when it can potentially be damaging to their "brand". (part of what has rubbed me the wrong way) ~~~ Frankly, shykes and other Docker employees shouldn't be commenting here. It only serves to make them look petty with any attempt of a "rebuttal"…

Actually, I appreciate that shykes and others take the time and try to explain their side of things and engage in a dialog. There's a lot of people confused right now about what's going on.

Re: CoreOS is building a container runtime, Rocket

#142

Post by shykes »

Alupis wrote: post #137
shykes wrote: post #127

Earlier quoted context omitted.

If you must know, the opposite just happened. Someone who happens to work at Docker just voiced their individual opinion. He was then reminded by "the PR machine" that it is better to take the high road and refrain from answering, and let the company make an official answer. This is pretty standard communication practices, and a good way to avoid feeding trolls like you. I know this, because I myself will get in trou…

> avoid feeding trolls like you. Interesting to see you resort to calling your users "trolls" simply because they feel it's not good for you, the head of Docker, to respond off-the-cuff and angry about a PR announcement from a competitor. > that it is better to take the high road and refrain from answering, and let the company make an official answer Your company already released an official announcement 2+ hours ago…

I'm just calling you a troll, and it's for implying that a cabal of Docker employees somehow manipulates and suppresses the public conversation about containers for the profit of their employers.

Re: CoreOS is building a container runtime, Rocket

#144

Post by sophacles »

philips wrote: post #94
bjt wrote: post #91

Earlier quoted context omitted.

I'm still digesting the Go-like syntax for vanity URLs and how that works here. If a fileset manifest lets you specify the URLs where the layers can be fetched from, then I like it. Does Rocket just 'cp' files on top of each other to implement layering? It'd be nice to not require a bunch of copies of the same files. I thought that the hard link implementation in Docker's new overlayfs support was a smart idea.

Yes, all of this was designed with overlayfs in mind. I am waiting anxiously for Linux Kernel 3.18 to land, this is a huge step forward for Linux and years in the making.

Cool! The idea of filesets is very nice - there are some very interesting workflow ideas buried in there. I've been looking forward to a mainstream unioning filesystem for a while too - and I hope rocket does some serious exploration (or enables it) of how to take advantage of them fully in both development and deployment. (And while I'm at it, testing too).

My personal wish-list down this path includes:

* options in the relevant manifests on which layer is writable ... if I'm doing development on libfoo which is used by several different apps, let me make that layer writable so I can rapidly iterate integration tests and (bad practice) live coding on testing/dev servers.

* tools to help me smash a dev layer or 3 into a single fileset (and similarly dissect a layer into a few new filesets during a refactoring)

* the ability to use filesets and overlays in a way similar to package management is now, but with extended features that are similar to python's virtualenv.

One of the things I see as a boon of the filesets as described is: I can update parts of my system without having to rebuild the whole dang app silo from the get go. Combining this with some of the above features looks like it could be useful for making "thin" images - where I can build all my code in one place, and port only the binaries to the staging and deployment images, just by doing a few fileset/overlay tricks. (no more complicated scripts)

Re: CoreOS is building a container runtime, Rocket

#145

Post by sagichmal »

shykes wrote: post #142
Alupis wrote: post #137

Earlier quoted context omitted.

> avoid feeding trolls like you. Interesting to see you resort to calling your users "trolls" simply because they feel it's not good for you, the head of Docker, to respond off-the-cuff and angry about a PR announcement from a competitor. > that it is better to take the high road and refrain from answering, and let the company make an official answer Your company already released an official announcement 2+ hours ago…

I'm just calling you a troll, and it's for implying that a cabal of Docker employees somehow manipulates and suppresses the public conversation about containers for the profit of their employers.

    > I'm just calling you a troll, and it's for implying that 
    > a cabal of Docker employees somehow manipulates and 
    > suppresses the public conversation about containers for 
    > the profit of their employers.
Really? This strikes you as a good idea?

Re: CoreOS is building a container runtime, Rocket

#146

Post by kapilvt »

wmf wrote: post #126
MyDogHasFleas wrote: post #120

Earlier quoted context omitted.

Yes and Pivotal (CloudFoundry) has posted a fairly supportive blog entry on Rocket. So it's not just CoreOS "making a play". https://news.ycombinator.com/item?id=8683540

Cloud Foundry also quietly forked Docker with Warden/Diego (edit: I meant Garden, thanks kapilvt), although in that case they remained compatible with Docker images.

clearing up some facts.. warden predates docker, its a container impl. diego is something entirely different more like kubernetes or mesosphere (scheduling & health, etc). garden the go implementation of warden containers does add fs compatibility for docker.

Re: CoreOS is building a container runtime, Rocket

#147

Post by ozzyjohnson »

billconan wrote: post #54

This may be a noob question, I'm looking into using containers for ui applications. I need to access GPU within the application. is this doable with Rocket or Docker? Also does Rocket have to be used with CoreOS?

Have a look at this container [1] I put together for accessing GPU instances on AWS via Docker. Runs various compute tasks including multiple containers against a single GPU without issue.

From the looks of your other comments in this tangent it might be exactly what you need or a starting point at least.

It's a base for these BOINC [2] and F@H [3] containers.

1: https://registry.hub.docker.com/u/ozzyjohnson/cuda/

2: https://registry.hub.docker.com/u/ozzyjohnson/boinc-gpu/

3: https://registry.hub.docker.com/u/ozzyjohnson/cuda-fah/

Re: CoreOS is building a container runtime, Rocket

#148

Post by Alupis »

shykes wrote: post #142
Alupis wrote: post #137

Earlier quoted context omitted.

> avoid feeding trolls like you. Interesting to see you resort to calling your users "trolls" simply because they feel it's not good for you, the head of Docker, to respond off-the-cuff and angry about a PR announcement from a competitor. > that it is better to take the high road and refrain from answering, and let the company make an official answer Your company already released an official announcement 2+ hours ago…

I'm just calling you a troll, and it's for implying that a cabal of Docker employees somehow manipulates and suppresses the public conversation about containers for the profit of their employers.

You came here with the explicit intent of disseminating your viewpoint that CoreOS is making a terrible decision and why your company and it's ideals are better. Your company already made an official PR response, leave it at that. (and you call me a troll?)

For the first time in Docker's short history, it's future and mission are being directly challenged. This is your response? (it won't be the last time Docker is directly challenged).

Imagine if Microsoft went around rattling the cage every time Apple released some product -- it would make them look pretty petty pretty quickly. Just get out there and compete. Produce a superior product and the market will speak.

Re: CoreOS is building a container runtime, Rocket

#149

Post by ascendantlogic »

shykes wrote: post #142
Alupis wrote: post #137

Earlier quoted context omitted.

> avoid feeding trolls like you. Interesting to see you resort to calling your users "trolls" simply because they feel it's not good for you, the head of Docker, to respond off-the-cuff and angry about a PR announcement from a competitor. > that it is better to take the high road and refrain from answering, and let the company make an official answer Your company already released an official announcement 2+ hours ago…

I'm just calling you a troll, and it's for implying that a cabal of Docker employees somehow manipulates and suppresses the public conversation about containers for the profit of their employers.

You're just digging a hole here. Better to take your own advice and take the high road.

Re: CoreOS is building a container runtime, Rocket

#150

Post by ash »

cpuguy83 wrote: post #80
mwcampbell wrote: post #49

Earlier quoted context omitted.

Nice. It occurs to me that since an ACI is just a tarball, the build process is decoupled from the runtime engine, unlike in Docker. I've found the Docker build process to be unsuitable for creating minimal images (though I've read that nested builds plus layer squashing will fix this). It'll be interesting to watch the exploration of different build tools and processes that Rocket's decoupled approach will enable, i…

Docker can import any tarball as a rootfs for a container, essentially allowing you to use whatever build tool you want. Dockerfiles/`docker build` is an implementation of a build system which uses the docker engine to make said rootfs.

Yes, but the actual container image that is being distributed can only be created by Docker. The ability to import is nice, but irrelevant here.
Post reply on HN