Hacker News Reader

Comment by pquerna | Hacker News Reader

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/

View on HN

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.

Looking back from the long-term future, though, what's the difference between the two approaches?

Whether the work on a standard container format happens inside or outside of Docker, it would result in a format presumably a bit different from how Docker containers are now (e.g. not overlay-layered by default, since most build tooling wants to just output an atomic fileset.) And either way, work would then occur to make Docker support that standard format.

The only real difference is that, in this approach, the ecosystem also gets a second viable runtime for these standard containers out of the deal, which doesn't seem like a bad thing. You can't have a "standard" that is useful in a generic sense without at least two major players pulling it in different directions; otherwise you get something like Microsoft's OpenDocument format.

> 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.

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.

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

In theory, OVF is the 'answer' for Virtual Machines -- but its failure has been in adoption -- if you can't get Amazon and OpenStack to adopt it, what's the point?

Before Rocket/ACI there wasn't even a contender for Containers. Now there is a published spec. Start there. Iterate.

I don't disagree, but OVF is an ANSI[1] & ISO[2] standard. Like you said, Amazon & OpenStack have chosen not to adopt it.

[1] http://webstore.ansi.org/RecordDetail.aspx?sku=INCITS+469-20...

[2] http://www.iso.org/iso/home/store/catalogue_tc/catalogue_det...

Just goes to show that adopted+working is more important and useful than a published spec.

Yeah, just try using OVF with containers and you'll discover how much of a round peg/square hole fit you are describing. VM's and containers are surprisingly different.

> 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?

Is what I should have quoted in my reply. Nobody was talking about using one instead of the other. Though, it'd be easy enough to run, for instance, CoreOS from an OVF image to run containers from. Though, I feel like you and I are just stating the obvious at this point. Wouldn't you agree?

I would.

Yes, it is always massively disappointing with every release of Parallels Desktop for Mac that OVFs and OVAs are not supported; they blindly continue to support just their own disk format whilst pushing their "enterprise" solution - surely OVF and OVA deployments are essential in that environment???

Sigh!

This'll be the last version of Parallels that I buy (thanks Yosemite)

Reply on news.ycombinator.com