221–230 of 295 posts
Earlier quoted context omitted.
I think using JSON is a solid choice. You can easily make yaml to JSON translators for this purpose.
JSON is okay, but I hope TOML will gain traction soon. Because comments. And trailing commas. Rust Crate is already using TOML for package metadata. https://github.com/toml-lang/toml http://doc.crates.io/manifest.html
I hope Rocket will be more stability oriented than Docker. After runing few hundreds containers on machine for almost a year know I would not chosen Docker again. Docker has stability issues all the time and it is taking months to solve them. Offering strace logs to developers without feedback and finally it was fixed by someone from outside the project. https://github.com/docker/docker/issues/7348 Allocating ports p…
Wow. That issue has been open for a long time.
I'm all for a new container runtime if it lets me start containers as a non-root user. Allowing non-root users to start containers would open up a whole new level of applications, particularly on multi-tenant HPC-style clusters.
Yes, finally! I've been working around this by making users inside the containers that people launch jobs on, but it would be much easier if they could do it individually in their own namespace (not using a docker group either).
Earlier quoted context omitted.
It's really bugging me people are using the word "fork". This is not a fork, it's a competing container format, there isn't any docker code in Rocket AFAIK. Even @shykes called it a fork in a comment, it's not somebody taking your code and doing something different with it, they are doing their own implementation. Ideas aren't "forked", code is. As to everything else, I manage CoreOS clusters with docker for now, and…
IMO rewriting something from scratch is like forking but worse because it's impossible to merge later. And Rocket is definitely forking the Docker community.
Often, starting from scratch is better. This is especially true when the goals or philosophy of the two projects are fundamentally different and incompatible, even if they perform similar tasks. Again, linux vs windows example applies.
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…
I don't have a horse in this race, but from what I read this is the part that can be construed as "slinging mud". I've put some [read between the lines] comments in square brackets: "Unfortunately, a simple re-usable component is not how things are playing out. Docker [much to our dismay] now is building tools for launching cloud servers, systems for clustering, and a wide range of functions: building images, running…
Earlier quoted context omitted.
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 i…
One could have just as easily said the same thing when the Docker format was introduced. The OpenVZ template format works well and is very similar to the proposed ACI format. The Docker format hasn't been without issue/problems.
Earlier quoted context omitted.
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…
I think it's called OVF[1]. It's just not as widely supported as it probably should be. [1] - http://en.wikipedia.org/wiki/Open_Virtualization_Format
Earlier quoted context omitted.
It isn't tied to systemd. The stage1 that is in the current prototype uses systemd to monitor and fork processes but we would love to see other stage1's that configure other process runners. For example configure and run a qemu-kvm filesystem as the container. Also, even though it is using systemd to monitor and fork processes a design goal is to run on all Linux's that have a modern Kernel.
The app container specification has socket activation in it. This is going to essentially tie it to systemd. Otherwise you will need another daemon running to do the socket activation, but then that would seem to be a "fundamentally flawed" execution model.
Every open source project starts off so well, then the "founders" decide they want to be gazillionaires, and it's all downhill from there. Sad.