[1.0.0] Need actual independent implementations

[cyphar]

Currently we don't have any canonical independent implementations of the specification. Docker's image format is different to ours (even though the base came from them), and rkt doesn't have support for ours.

As a result, this spec is entirely untested as we don't have any code implementing the spec word-for-word. As several people have discussed on the mailing list, this should be considered a blocking issue for 1.0.

Personally, I would want to have two implementations of the image-spec (like we do with the runtime-spec) before we can consider this ready. Preferably these implementations would be part of Docker and rkt (and have a reasonable cook time).

[philips]

The OCI image format is not different than the Docker image format. Changing the single media-type string constant doesn't make the format schema different. And on top of that we have added tests, documentation, JSON schema, etc.

We have one independent implementation of the specification, the oci-image-tool in this tree. But, lets say we have working patches today for Docker and rkt today. Then how long would we have to wait after that to say it is "tested". Does it need to be merged? How many releases?

My opinion: it would be nice to have independent implementations ahead of the release but we are hitting a chicken-and-egg situation here and delaying a release isn't going to fix the situation. The OCI is mandated in the governance docs to be compatible, section 7.g:

The first version of the OCI Specification should strive to be backwards compatible with the initial container image format and runtime contribution.

And the format we have here today is schema identical with systems widely used in production: Docker Hub, Docker Engine, rkt, etc.

[cyphar]

We have one independent implementation of the specification, the oci-image-tool in this tree. But, lets say we have working patches today for Docker and rkt today. Then how long would we have to wait after that to say it is "tested". Does it need to be merged? How many releases?

AFAICS this code (specifically the unpacking code) was merged 8 days ago. Am I misunderstanding something? The validation code is older than that, but my understanding of image-spec is that we define a format so that people can implement unpacking tools. Ours has only been in mainline for a week(!).

delaying a release isn't going to fix the situation.

Who decided that we have to release 1.0.0 this month? The use of the word "delaying" makes it sound like it's set in stone. It's not. The original PR went through less than a day of cook time, and there wasn't any linked mailing list discussion of roadmaps. Maybe those discussions happened somewhere else, but the fact that there isn't even a link to them doesn't inspire confidence.

Also, can I please draw our attention to the fact that the "examples" in the README don't work, because we don't have code in either Docker nor rkt that actually allows people to use this image format.

And the format we have here today is schema identical with systems widely used in production: Docker Hub, Docker Engine, rkt, etc.

So it should be trivial to write PRs to get code merged upstream, right? If it's schematically identical, all of the differences are minor, etc -- why don't we actually write some code and merge it upstream to prove that we are serious about 1.0.0?

[philips]

@cyphar The decision and rough milestones were ratified by the OCI TOB in March of 2016. You can find the mailing list thread here: https://groups.google.com/a/opencontainers.org/d/msg/tob/KGyPpu8YfNk/JnOvOEdSBQAJ

[cyphar]

@philips Do all maintainers still agree with the roadmap? It doesn't look like the community agrees IMO. Maybe we should hold another vote?

[vbatts]

See also https://tools.ietf.org/html/rfc5657

[vbatts]

@philips mentioned rkt now supports OCI image format https://groups.google.com/a/opencontainers.org/d/msg/dev/Am7byGvLCUQ/ywbuVLY3BQAJ
https://github.com/coreos/rkt/releases/tag/v1.11.0

[vbatts]

Skopeo now supports OCI image format and layout https://github.com/projectatomic/skopeo, via the https://github.com/containers/image library. /cc @runcom

[philips]

rkt supports fetching and running OCI images: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/Am7byGvLCUQ

[stevvooe]

Here is the docker proposal for OCI support: moby/moby#25779.

[vbatts]

I think this is done now

[vbatts]

(this issue)

[runcom]

here is the WIP Docker PR for OCI support moby/moby#26369

[vbatts]

Criteria:

• copy image to oci w/ skopeo
• run with rkt
• load to Docker
• run w/ Docker
• save from Docker
• export and run w/ runc

[vbatts]

grootfs from CloudFoundry: https://github.com/cloudfoundry/grootfs/blob/c3da26e1e463b51be1add289032f3dca6698b335/fetcher/remote/docker_src.go

[caniszczyk]

Mesos is working on OCI support atm: https://issues.apache.org/jira/browse/MESOS-5011

Design doc: https://docs.google.com/document/d/1Pus7D-inIBoLSIPyu3rl_apxvUhtp3rp0_b0Ttr2Xww/edit?usp=sharing

[philips]

I am satisfied this is heading in the right direction; can someone put a README entry together with all of this?

[wking]

On Sun, Oct 23, 2016 at 10:56:25AM -0700, Brandon Philips wrote:

I am satisfied this is heading in the right direction; can someone
put a README entry together with all of this?

There's a lot of stuff in the current image-spec README. Do we want
to follow runtime-spec and put this information in implementations.md
1?

[philips]

@wking an implementations doc seems like a great idea!

[cyphar]

umoci is tooling that I've been working on, which will eventually be integrated into KIWI and OBS to allow for OCI images to built inside the Open Build Service.

[philips]

Amazon Elastic Container Registry (ECR) has added support to pull OCI images.

https://aws.amazon.com/about-aws/whats-new/2017/01/amazon-ecr-supports-docker-image-manifest-v2-schema-2/

https://docs.aws.amazon.com/AmazonECR/latest/userguide/image-manifest-formats.html

[vbatts]

I think this is good. Perhaps best to have a wiki page or similar for listing these things.

[vbatts]

oh we've disabled wiki. fair... perhaps just close this and folks can add comments if they feel inclined? Seems like it ought to be tracked somewhere, but not keeping this issue open indefinitely