Proposal: Implement OCI image downloader

[hustcat]

skopeo is a good image downloader, but it's belonged to projectatomic.

[wking]

The problem with a generic image-downloader is that the OCI doesn't define an HTTP protocol for accessing images. We could fetch image-layouts over HTTP (just like we already do for tar- and directory-backed image-layouts). I think adding support for that would be useful. And it would be fairly straightforward after #5, but you could land it before #5 if you don't mind updating some existing walker-style consumers.

[coolljt0725]

There is also a oci-fetch(https://github.com/containers/oci-fetch) can download oci image. I'm +1 on supporting this in image-tool.

[xiekeyang]

I think we can setup a new sub-command in image-tools repo, like oci-image-fetch, which help to fetch the image from like docker hub, to compress it to OCI image, as supporting resource for OCI image tools of validate and unpack.

[runcom]

I think we can setup a new sub-command in image-tools repo, like oci-image-fetch, which help to fetch the image from like docker hub, to compress it to OCI image, as supporting resource for OCI image tools of validate and unpack.

if mixing OCI and Docker is an option why don't we move https://github.com/containers/image under OCI? :)

BTW, there are already tools out there to do this, and since distribution isn't defined by image-spec I would not clutter the repo with this new command

[xiekeyang]

if mixing OCI and Docker is an option why don't we move https://github.com/containers/image under OCI? :)

BTW, there are already tools out there to do this, and since distribution isn't defined by image-spec I would not clutter the repo with this new command

I think it will be easier to debug and work for image-tools by adding the command. And we can make modification with probable change of OCI image. I don't think it will lead to clutter, and It seems little benefit to set up another repo.

[hustcat]

https://github.com/containers/image is a powerful library, it's great if move it under OCI.

[wking]

if mixing OCI and Docker is an option why don't we move https://github.com/containers/image under OCI? :)

I think image-tools should stick to implementing image-spec. Tools that bridge with other formats and APIs belong outside of opencontainers/. Of course, we should make the image-tools libraries easily extensible to those external projects don't have to re-implement our functionality.

[glestaris]

I agree with @wking in that since it's not part of the spec it shouldn't live here.

@runcom that would be an interesting mix. Since containers/image supports multiple sources and destinations it would be a good companion the rest of the OCI projects and it's literally the only missing part from being able to create a container from scratch by only using OCI tools.

[hustcat]

I think we could setup a library with some defined APIs(or interface). ｀container/image` or other tools can implement these APIs.

These Interfaces in contaiener/image are good examples. #2

[wking]

On Thu, Nov 03, 2016 at 07:53:11PM -0700, Ye Yin wrote:

I think we could setup a library with some defined APIs(or interface). ｀container/image` or other tools can implement these APIs.

There are some low-level CAS/ref interfaces in flight with #5. There are also some validation interfaces and a media type → intra-blob validator map in opencontainers/image-spec#403. I've been holding off on higher-level interface development while those are in flight, but yeah, I think interfaces are the way to go to build a stack of composable components.

[cyphar]

@hustcat Here's my opinion on the topic:

1. skopeo already exists. Not every project that implements OCI features needs to be under the umbrella of the OCI (this is important to remember IMO). I get the frustration that distribution is not defined by the OCI (though IMO this is a blessing in disguise because it allows people to be flexible about implementing downloaders), but skopeo is a very cool project that solves this problem in the interim. If all else fails you could just create a package with your OS package manager and call it a day.
2. https://github.com/containers/image is not an OCI-specific library, so I feel that putting it under the OCI would be counter-productive -- we cannot really guarantee that transports like docker: or openshift: are something that we're going to maintain properly (we're responsible for our own specification, not every container-related specification that exists). Again, it's something that I believe should be its own separate project.
3. Having independent implementations of the "core OCI tools" is actually a very good thing IMO, because it means that we can be completely sure that the specification is sane and is well-defined. Not to mention that it results in there being a proper community around the specification (something that is very important if we want to standardise container runtimes and images).

If you want to see what my implementation of some core OCI functionality is, take a look at umoci. It's an OCI image modification tool that allows you to create diff layers (unpack + repack) as well as modify the configuration of the image (config) and so on.

[hustcat]

oci-torrent: A tool to distribute OCI image with bittorrent