Rkt: Doc: OCI creates uncertainty around rkt

[kallisti5]

I'd really like to deploy rkt, however with the looming appc -> oci transition, i get stuck in a weird place:

1) I'm reluctant to write appc since it seems like it would be a waste of time given the ROADMAP
2) The oci support + documentation seems extremely weak + unusable at this point.

I completely love rkt, but the items above make arguments to use it tough. To solve the issues above, i'd like to see more documentation, information, and general timelines around the appc -> oci transition.

[blixtra]

There is no requirement for you to create appc images to use rkt. rkt supports running Docker images. For now this is transparently translated to an ACI using docker2aci. That'll probably change in the future but it would be more an implementation detail.

[mixmastamyk]

Agreed, the website is confusing. Not sure what to do. The reason I'm here is because I don't want to use any docker stuff.

Would prefer if rkt was put into maintenance, and a new rkt2 project was started, with new docs scrubbed of old stuff.

[tjdett]

@kallisti5 @mixmastamyk As somebody who's been struggling with the uncertainty around rkt's roadmap for at least a year now, I think you've got three options currently:

1. Build to Docker's format (using a Dockerfile or buildah), then docker2aci explicitly at some point in your build/deploy chain. This gives you many of the benefits of rkt image handling (as ACIs don't need layers or repository servers, and can be signed) without being welded to the old ACI format.
2. Use acbuild, which is stable though unsupported, until OCI support is available (at which point you switch to umoci, buildah, or whatever exists then).
3. Just use Docker's format, and rely on rkt internal image conversion. This has worse caching implications than (1), but avoids ACI entirely (in case you have managers who are wary of deprecated specs).

In almost every case now, you'll find (1) works better than (2). Use (2) if you want to control capabilities and isolators via the AppC spec, but keep in mind that conversion to OCI later could be non-trivial.

Sadly, this is really a step back from the situation in 2016, when ACI provided clear advantages over Docker. OCI Image is pretty much a Docker image spec, with architectural assumptions that obviously clash with the way rkt is designed.

Despite the rhetoric, I can't see ACI going away any time soon. If the rkt maintainers could see a way to indicate how long the see it remaining, and what ACI → OCI tooling would exist prior to it being deprecated (keeping in mind that CoreOS uses rkt internally), that would be very helpful.

[kallisti5]

A quick addition to anyone looking at this. appc != runc

• appc == ACI (rkt's original plan)
• runc == OCI (docker's plan)

https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/uo11avcWlQQ is pretty much required reading to understand any of this.

I honestly don't understand why rkt decided to suddenly change over from ACI to OCI.

ACI seemed perfectly fine and would provide a great ecosystem competitor to docker (and OCI). The learning curve wasn't bad and the tools seemed great. Maybe at least rkt can offer up reasons for the change in the documentation?

[blixtra]

I personally see ACI support staying in rkt for a long time to come. But having native OCI support remains a goal and can co-exist.

@kallisti5 I think your characterisation of OCI as "docker's plan" to be inaccurate. It was based off Docker the docker image format, but many features that were originally pushed by AppC found there way into that spec. But OCI has a smaller scope than AppC. OCI does not define image distribution, for example.

And, I would not call the desire to be OCI compatible a sudden change. There was a lot of work from many of those who have worked on rkt to get that spec defined.

But I do think, there can be improvements in the documentation around this. Something we'll try to look into in the near future.

[develar]

For newbie, that decided to use/try rkt, current situation is very strange. On official site acbuild is shown in the example to build image, but... on the GitHub project page I see "This project is currently unmaintained" and no official recommendation what to use. "umoci or buildah might be able" is not an answer :(, I need official recommendation like "now please use foobar instead of acbuild".

In this ticket I see more strange information like "OCI Image is pretty much a Docker image spec, with architectural assumptions that obviously clash with the way rkt is designed." that makes situation more strange :)

And what I should do so? Should I use acbuild or official recommendation is different? Could you please make note on https://github.com/containers/build site more clear?