search

appc / spec

App Container Specification and Tooling (archived, see https://github.com/rkt/rkt/issues/4024)
Apache License 2.0
1.26k stars 146 forks source link

logic around ImageId and version #463

Open n0rad opened 9 years ago

n0rad commented 9 years ago

I think there is a misconception around ImageId and version in manifests. I understand why there is both but the fact that sometimes it's version and sometimes it's is imageId that is required cause problems.

Especially around dependencies, today I don't know how to create a build workflow. example:

I have my.com/aci-es:0.1 and my.com/pod-es-log:0.1 that have the first one as a dependency.

The dependency is set with imageName and ImageId. Maybe I can get around this by calculating the hash of aci-es and set it dynamically into the manifest of pod-el-log, which is already a problem, but not the biggest.

But when I will go to prod and try to run pod-es-log I don't see how RKT will discover the right version of aci-es since discovery is done by Version.

n0rad commented 9 years ago

Found that I can set the version in labels instead of image name.

n0rad commented 9 years ago

It seems the imageId is mandatory, and discovery is not triggered (on rkt), so It still apply.

philips commented 9 years ago

@n0rad Can you provide a concrete example of how this is a problem? The imageID isn't really discoverable so it is mostly useful for content verification of dependencies.

n0rad commented 9 years ago

That's exactly my point, currently ImageID is mandatory in pod manifest and shouldn't, since we cannot do discovery by ImageID.

Currently to be able to run a pod, you have to have the images already available in the local storage. But If I download the pod manifest on an empty prod machine and try to run it, rkt have to fetch the images of the pod (and should do it using name+version), without any imageID.

jonboulle commented 9 years ago

@n0rad ImageID is mandatory at final pod execution time but not necessarily when using a pod manifest as a deployment template. For example, https://github.com/appc/spec/blob/master/examples/pod_template.json#L13 compared to https://github.com/appc/spec/blob/master/examples/pod_runtime.json#L37 - in this case we can imagine that the implementation which use the template manifest as an input (as rkt can) proceeded to discover the backup image basedon its labels and then reify the manifest with the image ID. Does this answer your question?

n0rad commented 9 years ago

Ok, I think I got it why ImageID is mandatory in the spec. Now It seems RKT is not processing the discovery to transform the template to runtime.

n0rad commented 9 years ago

https://github.com/coreos/rkt/issues/1316