Skip to content
This repository was archived by the owner on Feb 24, 2020. It is now read-only.
This repository was archived by the owner on Feb 24, 2020. It is now read-only.

Support for OCI runtime and image specification. #2541

@sgotti

Description

@sgotti

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 list with 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?
  • 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?

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions