This repository was archived by the owner on Feb 24, 2020. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 877
This repository was archived by the owner on Feb 24, 2020. It is now read-only.
Support for OCI runtime and image specification. #2541
Copy link
Copy link
Open
Milestone
Description
I don't know if someone is already thinking/working on this but I'd like to share my thoughts and hear yours.
Since, after the oci runtime spec, also the oci image spec is taking shape, I started thinking on how to implement this in rkt.
Possible steps:
OCI Image spec
Currently the OCI image spec is made of different media types that should be fetched (the OCI image spec doesn't cover distribution) and stored.
- Implement an OCIStore. The current rkt store is built around the appc/spec ACI images, it should probably be enhanced to also handle the OCI image format but probably, since the two specs are quite different, a dedicated store will be cleaner. It will have multiple diskv stores and a db to save the various media types by their digest (related store: add support for multiple hashAlgorithms. #2479, store: using native content addresses for docker image layers #2313)
- Implement OCI image rendering (from multiple layers).
- Implement inside the OCIStore a TreeStore that will render the OCI image (similar to the current ACI treestore) (and put the OCI runtime config.json at its root).
- Implement OCI image fetching. Actually this should just cover only fetching from a docker v2 registry:
- Implement a DockerV2RegistryFetcher
Probably big parts of the docker2aci code should be used (copied inside rkt) for implementing the above steps.
OCI Runtime spec
One idea will be to convert the OCI runtime config to an ACI manifest (using oci2aci?) so the podmanifest generation and handling done in the stage0 and the various stage1s shouldn't be changed.
Questions
- since the scope of the OCI image spec is to be able to run an image by its image name string (like the ACI image string (https://github.com/opencontainers/image-spec#cooperation-with-oci-runtime-project) how to distinguish in rkt if an user want to run an appc/spec or an OCI image? Probably something like run from a local file UX #715 (comment) is needed.
- Actually I'll omit fetching/running images by file/url since it's not clear if there'll be an image bundle format (containing all the image layers, manifests etc...) or how to do this using multiple media types files/url (for example: how to fetch the layers if I only provide the image manifest? The ACI rkt implementation is different/simpler since given an aci it just goes to the store or does meta discovery to retrieve dependencies)
- How to show the different media types in the OCI Store?
- Use
rkt image listwith an additional type column? What to do if there're different fields between aci images and OCI images that makes this difficult to show in a single table? - Keep them separated and use a flag to choose between ACI or OCI images?
- What OCI image spec media type to show by default (they also will probably have different fields)?
- Just show the image manifest (since the layers are detached from it) and add some options to also show the layers?
- Use
- How to handle docker images for V1 and V2 repositories?
- keep using docker2aci special
docker://urls for both docker V1/V2 registries until it'll be deprecated by the OCI spec?). - keep using docker2aci special `docker:// only for V1 registries and move V2 handling inside the OCIStore?
- keep using docker2aci special
Reactions are currently unavailable