Ensure "dependencies" are possible

[vbatts]

Carrying over #35 (comment)

Like appc/spec ACI dependencies https://github.com/appc/spec/blob/master/spec/aci.md#dependency-matching

Ensure that OCI image spec can support an image (config plus descriptors) that includes references to dependent layers that may themselves include its own config.

To some extent, this would satisfy #39

[stevvooe]

Are we interested in dependency or history?

The main issue with dependencies is that it requires a way to merge configuration. This is much easier if this merge is done at build time, where it can be controlled and deterministic.

In general, dependencies really belong at build time. We can always trace back common components through content-addressing, but carrying dependency information into the image doesn't really provide much.

Otherwise, the image format degrades into an linked list.

[philips]

@stevvooe the objects required for the linked list could be collected ahead of time by the person signing the version. I agree in general that things should be immutable. Walking the linked list post-transport isn't expensive. This was always the intention with AppC, we just didn't get to it as the linked list is generally "short".

[stevvooe]

@philips So, does this become a side-chain? Where does that reference land?

[kamalmarhubi]

Here is a use case that I think should be possible: I want to compose an image out of a binary that dynamically links against libssl. I would like to compose the image out of two layer blobs so that

1. I can audit versions of libssl I have running, and
2. I can push out an update without having to rebuild the blobs every container image I have out there.

Another is the one I mentioned in #39, of composing an image out of a server binary and served data blobs. I would like to be able to update each independently of the other. In Kubernetes, this would happen one level up by composing two images as a pod, but for other systems that abstraction is not available.

[kamalmarhubi]

(There was a fantastic blog post about container packaging systems that I can't find now, but it gave lots of ideas of things you would like to do , and know about your running system.)

[stevvooe]

@kamalmarhubi So, are you willing to trust the metadata indicating which version of libssl is present in the image? Deep scanning is the only way to guarantee this.

Another is the one I mentioned in #39, of composing an image out of a server binary and served data blobs. I would like to be able to update each independently of the other.

This really seems like a runtime concern. Because the references are content addressable, updating one or the other component really introduces a new artifact. Implementations can find creative ways to distribute that artifact efficiently.

In Kubernetes, this would happen one level up by composing two images as a pod, but for other systems that abstraction is not available.

Exactly, but this has no place in the image format specification. Compose them at runtime.

[philips]

@stevvooe I would argue if you can't trust the metadata of the person pushing the binary then you shouldn't trust the binary either. But, I don't think this is really the forum for this discussion.

[stevvooe]

I would argue if you can't trust the metadata of the person pushing the binary then you shouldn't trust the binary either.

While my statement above mentioned trust, this is less about malice than it is ensuring the right metadata lands in the right place. A small bug or incorrect metadata can be costly and the only way to catch it is to actually fingerprint and scan the content.

[philips]

@vbatts I think this should be moved out of the v1.0 path. Anything we do here will likely break compatibility with Docker v2.2 and we should strive for compatibility in the first version. Any objection to me moving this to post-v1.0.0?

[vbatts]

I'm not opposed to that. I think I'd hoped the naming discussion would have
yielded something that this issue could lean on.

On Wed, Jun 8, 2016, 18:56 Brandon Philips notifications@github.com wrote:

@vbatts https://github.com/vbatts I think this should be moved out of
the v1.0 path. Anything we do here will likely break compatibility with
Docker v2.2 and we should strive for compatibility in the first version.
Any objection to me moving this to post-v1.0.0?

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
#102 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AAEF6a8SCq9S6Z89Alfgn76-TBmdHnNkks5qJ1avgaJpZM4IrzTQ
.

[stevvooe]

@vbatts It might be okay to include a parent reference. There is already a history of rootfs diffIDs. I think if we clarify whether these dependency references are to manifests, image config or raw layers, we can make a clearer decision.

[philips]

@vbatts OK, moving it to post-v1.0 for now. I think we should focus on the required (base) layers in v1.0 and compatibility. After that we can discuss optional features and layers.

[vbatts]

also for the record, just history of the rootfs-diffIDs is not a full enough history for many audit processes.

[vbatts]

Ideally, this use-case would be covered by the references API