Questions: about the resolvedImageName and ImageName.

[Random-Liu]

Currently:

1. They are the same in docker resolver;
2. The resolvedImageName is expected to be put into image metadata store.

The problem is that:

• Will they be different in the future?
• If they are different, does it mean whenever a container wants to use a image already pulled on the node, it needs to resolve the image name again to get the resolvedImageName and then the image metadata?
• Does it mean that container can not use the image already pulled on the node without network connection?
• Do we need to maintain the ImageName -> ResolvedImageName mapping, and do the local resolution outside of containerd?

/cc @stevvooe @dmcgowan

[dmcgowan]

I see the code is currently putting the resolved image name as the image tag. My understanding is that it should use the passed in ref and if they differ possibly add the resolved ref. I don't think we should be relying on the resolver to do canonicalizing since we are trying to force the clients to define and enforce those outside the scope of remote resolution. If the resolved name does not match the passed in name, I figure that it would only be valuable to the client as metadata or for logging rather than tracking. @stevvooe might have more of an opinion on what the role should be going forward

Will they be different in the future?

Not for the Docker resolver since we are currently requiring canonical names.

[stevvooe]

I see both as being targets for saving.

Let's say you do the following:

resolved, err := Resolver.Resolve("docker.io/library/ubuntu:latest")

This allows the resolver, which is the image namespace controller, to canonicalize to a particular tag or qualified name. This could return docker.io/library/ubuntu:17.04. Both should be considered correct references for the image, and both can stored in the image store.

I actually thought of making this return a slice of references that could be stored in the image service.

To answer the questions in line:

Will they be different in the future?

Yes.

If they are different, does it mean whenever a container wants to use a image already pulled on the node, it needs to resolve the image name again to get the resolvedImageName and then the image metadata?

No, it can resolve from the image metadata service.

Does it mean that container can not use the image already pulled on the node without network connection?

No. Where is that implied?

Do we need to maintain the ImageName -> ResolvedImageName mapping, and do the local resolution outside of containerd?

That is up to you. I would just write it into the metadata store.

I think what we might be missing here is a local resolver that operates on the image store.

[Random-Liu]

Does it mean that container can not use the image already pulled on the node without network connection?

No. Where is that implied?

If we only put the resolved name into image store (current behavior), then we need to resolve the image name again whenever we use the pre-resolved image name to reference the image.

However, if as you said, we should put both into the store, then the problem is resolved.

[crosbymichael]

I believe this has been resolved. Let me know if not.