jzxcv

We aren't actively testing against it yet (although plan to in future), but have heard reports from the community that it works fine: https://github.com/coreos/rkt/pull/1766#issuecomment-1578394...

Could you explain what you mean by "locks you in"?

There are certainly a few ways this could work; for example, since Rocket currently uses a generic CAS backend to store assets, and is designed to expect multiple simultaneous invocations (using filesystem locking etc), it's feasible for an external service to be pulling down images out of band that Rocket could then consume.

(disclosure: another CoreOS employee)

> When it comes to distributing container images the ACI spec only requires hosting ACI images (tarballs) behind a HTTP webserver

Just to clarify a little: the spec [1] actually only stipulates that the _metadata_ for image discovery is provided over HTTPS. The actual ACI images (i.e. tarballs) can be distributed using any desired mechanism. For example the meta discovery service can provide HDFS and BitTorrent addresses, and then a client can choose how to retrieve the payload. This is one of the parts of the spec I'm personally most excited about, so would welcome feedback and/or implementations!

[1] https://github.com/coreos/rocket/blob/master/app-container/S...

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

Yep, this is _exactly_ one of our design goals. ACIs are trivially buildable and inspectable with standard Unix tools.