Celebrating the Open Container Initiative Image Specification
1–10 of 19 posts
Re: Celebrating the Open Container Initiative Image Specification
#2CoreOS has done a lot of work to avoid a monoculture of Docker containers, and I think we all benefit from the interchangeability of different implementations/runtimes.
The future of containers just keeps getting brighter and brighter.
Re: Celebrating the Open Container Initiative Image Specification
#3I thought that's what AppC was supposed to be? Does that mean AppC is moribund?
Re: Celebrating the Open Container Initiative Image Specification
#4I thought that's what AppC was supposed to be? Does that mean AppC is moribund?
No, appc isn't moribund; the appc community continues to maintain the spec[1][2]. Our hope is that the best parts of the appc will be added into the OCI for a shared industry standard. And today I am optimistic the OCI will do that.
The OCI membership includes important parties in the ecosystem from container engine implementers to public providers with container registries: Google, Microsoft, Amazon, Docker, CoreOS, Red Hat, and many others. This means that we have good a organizational setup to get a single industry standard. It is worth the additional effort to obtain that goal for the industry.
tl;dr appc is a source of inspiration for the OCI work and will continue to be maintained and available in rkt, Quay, and others. We have a good shot at an industry standard for container images. And we want to make that successful even if it requires some initial duplicated effort.
[1] https://github.com/opencontainers/image-spec#faq
[2] https://coreos.com/blog/making-sense-of-standards.html
(CTO of CoreOS, OCI Technical Oversight Board member)
Re: Celebrating the Open Container Initiative Image Specification
#5Wait, they don't use hashes? Why???
Image ID
Each layer is given an ID upon its creation. It is represented as a hexadecimal encoding of 256 bits, e.g., a9561eb1b190625c9adb5a9513e72c4dedafc1cb2d4c5236c9a6957ec7dfd5a9. Image IDs should be sufficiently random so as to be globally unique. 32 bytes read from /dev/urandom is sufficient for all practical purposes. Alternatively, an image ID may be derived as a cryptographic hash of image contents as the result is considered indistinguishable from random. The choice is left up to implementors.Re: Celebrating the Open Container Initiative Image Specification
#6I thought that's what AppC was supposed to be? Does that mean AppC is moribund?
No, appc isn't moribund; the appc community continues to maintain the spec[1][2]. Our hope is that the best parts of the appc will be added into the OCI for a shared industry standard. And today I am optimistic the OCI will do that. The OCI membership includes important parties in the ecosystem from container engine implementers to public providers with container registries: Google, Microsoft, Amazon, Docker, CoreOS,…
Your first link says this:
>>Q: What happens to AppC or Docker Image Formats?
>>A: Existing formats can continue to be a proving ground for technologies, as needed...
Sounds pretty moribund to me. It exists only if it wants to be a proving ground, "as needed".
Re: Celebrating the Open Container Initiative Image Specification
#7Wait, they don't use hashes? Why??? Image ID Each layer is given an ID upon its creation. It is represented as a hexadecimal encoding of 256 bits, e.g., a9561eb1b190625c9adb5a9513e72c4dedafc1cb2d4c5236c9a6957ec7dfd5a9. Image IDs should be sufficiently random so as to be globally unique. 32 bytes read from /dev/urandom is sufficient for all practical purposes. Alternatively, an image ID may be derived as a cryptograph…
Maybe don't paste into a horizontal scrollbox so that you may see the whole thing?
It says:
>an image ID may be derived as a cryptographic hash of image contents
Re: Celebrating the Open Container Initiative Image Specification
#8Weren't containers supposed to solve the whole "one interface for everything" nonsense? Now we have a standard interface for the standard interface?
Re: Celebrating the Open Container Initiative Image Specification
#9Wait, they don't use hashes? Why??? Image ID Each layer is given an ID upon its creation. It is represented as a hexadecimal encoding of 256 bits, e.g., a9561eb1b190625c9adb5a9513e72c4dedafc1cb2d4c5236c9a6957ec7dfd5a9. Image IDs should be sufficiently random so as to be globally unique. 32 bytes read from /dev/urandom is sufficient for all practical purposes. Alternatively, an image ID may be derived as a cryptograph…
Maybe don't paste into a horizontal scrollbox so that you may see the whole thing? It says: >an image ID may be derived as a cryptographic hash of image contents
Using the crypto hash is something that we should probably fix up and enforce. Could you file a bug?
We just started the project last week and imported the original Docker v2.2, which this text is from, a few days ago. So, there is language that will change and improve before the initial v0.1.0 release.
Re: Celebrating the Open Container Initiative Image Specification
#10If only Blue Origin & SpaceX can behave this way too...