Live data from Hacker News

CoreOS is building a container runtime, Rocket

coreos.com

111–120 of 295 posts

Re: CoreOS is building a container runtime, Rocket

#111
post #100
post #92

Earlier quoted context omitted.

I think you're reading too much - or too little - into this if you think they're "slinging mud". Any fork is going to list its reasons for the fork- if they didn't have issues with how Docker is heading, why would they be making the fork in the first place? If they just quietly gave an ambiguous non-disparaging statement like "we're forking because we're unhappy with the direction Docker is taking", it would seem fri…

[deleted]

personally, I think the long term value of Rocket is not about Rocket -- its about the ACI specification for the formats of containers.

Right now I'm already taking a Dockerfile, exporting it to a tar, and then running systemd-nspawn -- I love Dockerfiles, I love being able to grab a postgres server and get it up quickly from Docker Hub, but I didn't need or want the rest of docker.

If both Docker and Rocket support ACI, then you have a composable image layer, and that means people aren't locked into either ecosystem just to build images of their applications.

ACI :: Docker-tar-format to me is like QCOW2 :: VMDK. Wouldn't it be cool if projects like Packer[1] didn't have to exist, because the image format of Virtual Machines was open and documented as an independent standard?

[1] - https://www.packer.io/

Re: CoreOS is building a container runtime, Rocket

#112
post #87

Hi, I created Docker. I have exactly 3 things to say: 1) Competition is always good. Lxc brought competition to openvz and vserver. Docker brought competition to lxc. And now tools like lxd, rocket and nspawn are bringing competition to Docker. In response Docker is forced to up its game and earn its right to be the dominant tool. This is a good thing. 2) "disappointed" doesn't even begin to describe how I feel about…

What's with all the drama? Did we read the same announcement? What is it that we end users don't know?

Docker and CoreOS are in a pre-monetization land grab for a single market.

They've so far been approaching it from opposing corners, but CoreOS just made the first play at the opponent's territory, and it apparently rattled Docker a bit.

I am excited to have more viewpoints in play.

Re: CoreOS is building a container runtime, Rocket

#113
Hmm, I played around with CoreOS for the past weeks, it was nice, I'm getting the hang of it. What is constantly difficult though is that there is no cross linking of containers (mysql database accessible from user@172.ip.add.r while the Nginx/PHP-fpm docker is looking for a specific mysql ip addr). Restarting containers from images changes both IPs. Not handy. Why not always share a common /etc/hosts with all current containers (given name with current ip addr) in them?

I was also having some issues with php5-fpm in a docker, it doesn't seem designed for it (it gets the file paths communicated from Nginx, not the files so dockers need to sync files)

Somehow I though CoreOS and Docker would be figuring this out together. I hope somehow that the knowledge I now have will remain relevant, I was planning a hosting service for sports clubs based on drupal8.

Ah well, we are at the beginning of an era, I should have expected this. I'm very curious, who knows, the container space is far from filled, we'll be seeing many distros. There will be Gentoo's, there will be Ubuntu's. It's going to be nice.

Re: CoreOS is building a container runtime, Rocket

#114
post #87

Hi, I created Docker. I have exactly 3 things to say: 1) Competition is always good. Lxc brought competition to openvz and vserver. Docker brought competition to lxc. And now tools like lxd, rocket and nspawn are bringing competition to Docker. In response Docker is forced to up its game and earn its right to be the dominant tool. This is a good thing. 2) "disappointed" doesn't even begin to describe how I feel about…

My +1 goes to Kelsey Hightower. He posted on 7 Nov some worries which many Docker users and contributors, already had since the past year, when you dropped off LXC containers, instead of working together with https://linuxcontainers.org/ project to get a better code. That seems already a strategic business decision to decouple your "product value" from his mother and generator: LXC. IMO, Docker's 'new' direction completely ignored the tremendous amount of support they had from the sysadmin and devops communities.

Re: CoreOS is building a container runtime, Rocket

#115
post #100

Earlier quoted context omitted.

[deleted]

personally, I think the long term value of Rocket is not about Rocket -- its about the ACI specification for the formats of containers. Right now I'm already taking a Dockerfile, exporting it to a tar, and then running systemd-nspawn -- I love Dockerfiles, I love being able to grab a postgres server and get it up quickly from Docker Hub, but I didn't need or want the rest of docker. If both Docker and Rocket support…

Now we're talking. Yes, I agree having a better spec for the underlying image format would be nice. In fact I also agree you should be able to use the Docker runtime without its packaging system, and vice-versa.

However I think it makes more sense to do this on the actual Docker format which everyone already uses... That way you get the benefit of increased openness without the drawback of fragmentation. I have the impression I've been pretty vocal in asking for help in making this happen, and wish these guys had stepped in to help instead of forking. I pretty distinctly remember pitching this to them in person.

So, I'll re-iterate my request for help here: I would like to improve the separation between the Docker runtime and packaging system, and am asking for help from the community. Ping me on irc if you are interested.

Re: CoreOS is building a container runtime, Rocket

#116
post #94
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.

Whether Velociraptor uses Rocket or not, implementing the App Container Spec seems like a no brainer. I've made https://bitbucket.org/yougov/velociraptor/issue/136.

Re: CoreOS is building a container runtime, Rocket

#117
post #93

Earlier quoted context omitted.

All of which will be fully pluggable with a "batteries included but removable" design, just like we did with sandboxing and storage.

You may need to make that clearer to some of the people that are due to be building your plugins: reading http://weaveblog.com/2014/11/13/life-and-docker-networking/ , I get the feeling that they're not thrilled about it.

maybe they're busy designing the interface and implementing a proof-of-concept with us as we speak, instead of blogging and twittering.

Re: CoreOS is building a container runtime, Rocket

#119
post #58

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?

I'm interested: why do you need a container for a UI application? It would be better for your users if it could run as a simple process.

Not the parent poster, but needing GPU isn't necessarily the same as having UI. You can use GPU for a variety of general purpose math (Example: mining bitcoins, or doing stuff like Folding@Home), or for offline rendering.

Re: CoreOS is building a container runtime, Rocket

#120
post #112

Earlier quoted context omitted.

What's with all the drama? Did we read the same announcement? What is it that we end users don't know?

Docker and CoreOS are in a pre-monetization land grab for a single market. They've so far been approaching it from opposing corners, but CoreOS just made the first play at the opponent's territory, and it apparently rattled Docker a bit. I am excited to have more viewpoints in play.

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

Post reply on HN