rkt: Implement FetchImages and RemoveImages API through API service.

[yifan-gu]

Take the image service part from #2963 , which can be used in CRI depite pod level or container level interface.

cc @lucab @euank @tmrts @alban @iaguis @s-urbaniak

Ref kubernetes/kubernetes#30513

[yifan-gu]

OK, also added implementation on the two APIs.

[yifan-gu]

Manually tested with the updated client example, this works now.

$ sudo ./client_example 
Fetched image ID: sha512-86aa5fa7158bf69d9b1078f2c557b971315bf4304f3036c4518ebd26c7205cdf

[yifan-gu]

Feedback on this? Now the string is something like docker://busybox or coreos.com/etcd:v2.0.8 @lucab @sgotti

[sgotti]

I'll go with using the distribution concept from #2953. So image type is not needed for fetching. I left a comment for you there some days ago. Can you take a look at it?

[yifan-gu]

@sgotti Sorry, will do, just buried by other works..

[sgotti]

@yifan-gu no problem. I'd just like to collect more opinions as possible from people involved on the various parts that it'll affect/help.

[yifan-gu]

@sgotti I am not sure about the Type: Name vs Type: Location thing. At this point I can't see why Distribution is not enough to express the Name vs Location ?

Unless we combine Distribution: Appc with Distribution: ACIArchive, and Distribution: OCI with Distribution: OCIImageLayout.

[yifan-gu]

Also commented on the PR, let's discuss here (sorry for multiple comments)

[yifan-gu]

So for this PR, I intend to make ImageType + name able to locate and fetch the image into disk store.

[sgotti]

@yifan-gu with the distribution you only need one field (distribution string). The reason why you don't need the image type are explained in #2953

[s-urbaniak]

"defines the write-only APIs"

[yifan-gu]

@sgotti OK, I updated the PR, using one string (field Names) as the distribution string. But probably requires distribution string parsing logic.

[sgotti]

@yifan-gu you can just keep passing the docker:// pseudo URL since it's a recognised user friendly string (see #3101). In future the kubelet could also convert the k8s string format to the related distribution URI.

BTW @euank @yifan-gu do you see a possible path for suggesting the use of distribution point concept also for k8s (to handle multiple distribution types). I can't recall the issue but I remember something about also handling Appc images. As explained in #2953 I think that more than "multiple image types" the real concept will be "multiple distribution types". Probably k8s doesn't need to use Direct distribution points but only indirect ones (Docker, Appc and in future, when defined, a possible OCI distribution) and the distribution string exposed to the user could be an user friendly string like done by rkt. So just one string without the need to declare any other field in the json descriptors.

[yifan-gu]

@sgotti We can do that today, I once discussed with @euank about some similar idea, e.g.

...
container:
  image: foo
...

becomes docker://foo

...
container:
  image: aci://coreos.com/foo
...

becomes coreos.com/foo

One benefit is we can do that without changing k8s API. cc @philips

[sgotti]

That will be great!

Image: aci://coreos.com/foo -> coreos.com/foo

Not to be pedantic 😄 but, as explained in #2953 we are talking about distribution and not image types , so I won't use aci but appc.
Addionally this is related to appc/spec#586 (comment) where I put my thoughts on a URN vs a URL (appc: vs appc://)

[yifan-gu]

@sgotti Yes I got you, it was just an example :)

[sgotti]

@yifan-gu 👍 I was too much pedantic. sorry 😅

[s-urbaniak]

@yifan-gu bumping to next release, though I do remember we discussed OOB to drop this in favor of CRI?! Feel free to close if that is the case.

[yifan-gu]

closing for now, we can reopen if we finally decide to go down this path.