Appc Source and Destination about image HOT 12 CLOSED

/cc @sgotti

from image.

/cc @philips also

from image.

@runcom @philips my 2*10-2 €

• appc Destination: I'll convert the docker/oci config to an appc manifest and squash the layers in the appc rootfs (since given the ref vs appc name/labels it'll become a mess to map a layer to an aci). Basically what docker2aci does (I think we can borrow many things from it).

There're some special annotations added by docker2aci (https://github.com/appc/docker2aci/blob/master/lib/common/common.go#L33-L39) and some of them are needed by rkt (for example to detect a docker converted image to handle docker volume semantic rkt/rkt#2315). If we want the generated ACIs being directly and correctly usable by rkt they should be implemented.

• appc Source: I'll convert the appc manifest to a docker/oci config and fetch and render (for the above reason) the aci to a unique layer.

Implementing it we'll see how the interfaces work or if they need some changes.

from image.

I'm +1 on everything you said for appc Image destination - all the doubts around rkt specific pieces will be confined uner appc/ pkg so I don't mind having them if they're actually needed

I think we can start with the destination as it's pretty straightforward to do (I hope so) and re-iterate on the source

from image.

(I know about zero about appc, but :) )

The above suggests that both source and destination always do some kind of conversion. I hope that would work fine, and it would of course be very useful to be able to convert between formats; eventually we should also consider some kind of native support so that skopeo copy can do an appc→appc copy with no conversion (and in particular, without breaking the signatures).

I have no idea whether it would be easy enough, or how would that happen (DockerLikeImage{Source,Destination} and so on, and conversion logic in a copy library?); just throwing this out here as something to consider for the future.

from image.

@mtrmac good point!

@runcom @mtrmac before opening a new issue what about the idea of implementing a source->converter->output pipeline (a la gstreaner)

sources will register their output format(s)
outputs(destinations) will register their accepted input formats
converters will register their accepted input output formats

The lib will find a converter for the requested source and output and start the pipeline

There can be for example an oci2appc, appc2oci and a passtrought converters.

from image.

@sgotti Yes, I think we are moving in that direction (already #23 is doing some conversion). I would hate for this to end up a graph and Dijkstra path search unless we end up really needing it, but a source → single converter → output seems inevitable, as does turning most of skopeo’s copy.go into a library.

from image.

And FYI I'll soon want to add a docker tar image destination to output docker loadable tars

from image.

So oci2appcs or whatever makes sense for me

from image.

I would hate for this to end up a graph and Dijkstra path search

😄

from image.

@runcom @vrothberg @mtrmac Three year old issue? Should I just close?

from image.

Closing ✔️

from image.