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),…
(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…
> 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…
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),…
(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…
> 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…