Questions about Kubernetes CRI implementation

cri-questions.md

CRI QUESTIONS

This references the api spec and the high level description.

It should be noted that the high-level description is somewhat out of date. There are now only two services: RuntimeService and ImageService

1. How are PodSandboxes mutated?
2. Why does CreateContainerRequest also allow a PodSandboxConfig? Is this the preferred way to mutate a PodSandbox? What about cases where the sandbox is mutated outside of container creation?
3. What fields in a PodSandboxConfig can be used to mutate a running PodSandbox?
4. The PodSandboxStatus is missing some data:
5. No way to get the list of port forwards
6. No way to get the log_directory
7. The ContainerStatus is missing some data:
8. Missing log_path
9. Why do List(PodSandbox|Containers) return different types from (PodSandbox|Container)Status?
10. Are there uniqueness contstraints on mount names? Are they per-Container or per-PodSandbox?

1. Why is ImageSpec optional in ContainerConfig?
2. CreateContainerRequest has pod_sandbox_id as optional - that seems wrong

FYI, there is a plan we switch to proto3, which all fields are optional. So when the proto was defined, we intend to make them optional.

1.CreateContainerRequest lets one mutate either ContainerConfig or PodSandboxConfig - why is this? Will there ever be a time when the Sandbox is mutated without adding a Container?

Not 100% sure if we added PodSandboxConfig in the CreateContainerRequest because we want to mutate it, IIRC it's just because we need to know the value of it (then why not just passing pod sandbox ID?) cc @yujuhong @feiskyer for better answers to this.

5.Why are Container and ContainerStatus different?

ContainerStatus contains more detailed information like creation time, start time, exit code, etc. Basically container maps the the return value of docker ps, container status maps to docker inspect. I do think we are able to merge two of these, but it's not a blocking issue IMO.

1.What fields are required in the Mount request?

At least name, container_path, host_path will always be there.

2.Are mount names unique per-container or per-sandbox? What do they do?

Today kubelet don't guarantee the names to be unique even per container. And in today's rktnetes we totally ignore the names, instead we create a uuid for each mount to make them unique.

Probably we can get rid of the mount name, they are not visible to users anywhere.

1.How do you add a port mapping at container add time?

I don't know for sure, maybe CNI can handle it? How about the vm case? cc @euank @steveej

1.To what extent should the CRI data model dictate the internal rkt data structures?

What internal rkt data structure are you referencing?

@squeed How about we file to upstream?

@yifan-gu: Thanks for your comments! I've updated my questions, if that helps.