[kata-dev] sandboxID and containerID types

Beyer, Gabrielle N gabrielle.n.beyer at intel.com
Mon Jun 10 23:23:52 UTC 2019


I have been working on some slight code cleanup/refactoring within the kata-runtime, but I feel like there is not an extremely straight forward answer for fixing the issue of converting sandboxID and containerID to distinct types: https://github.com/kata-containers/runtime/issues/1024

The rest of this can be found as the most recent comment within the issue (with prettier formatting :))

There looks to be a few instances within the runtime/cli that containerID and sandboxID are used interchangeably, mostly seemingly due to the OCI spec being unaware of the sandbox. I think we may need to have a discussion about how we want to handle these specific situations (I'll post below some that I found). I am still trying to learn the code base and project, so please correct me where I'm wrong, or give advice in any way :)

First, a few clarifying questions I had:
1. In the docker case, are sandbox ID and container ID [always|usually|never] the same value?
2. In the kubernetes case, is the sandbox ID the pod ID or the "dummy/pause" container ID, or both?

### instances
from `cli/run.go`
`func run(ctx context.Context, containerID ContainerID, bundle, console, consoleSocket, pidFile string, detach, systemdCgroup bool,`

// delete container's resources
if err := delete(ctx, sandbox.ID(), true); err != nil {
    return err

however, in `cli/delete.go`, the delete function takes a container ID, not a sandbox ID.
Within the delete function it checks the `containerType`, and either performs a delete sandbox, or delete container depending on the type.


There is a similar situation in `cli/start.go` where sandboxID is being passed where ContainerID is expected to run the hook:
return katautils.PostStartHooks(ctx, ociSpec, sandboxID, status.Annotations[vcAnnot.BundlePathKey])`

A final instance I'm slightly confused on (also probably with my inexperience with all of this, so bear with me) is with the `getExistingContainerInfo` func within oci.go. It seems to be returning the ID of a sandbox, yet is eluding that it is getting container information. I'm not sure if this is a naming thing, or if it goes along with the question of whether these variables should be implicitly called.

which leads me to ask. do you think we should:
1. keep things how they are and implicitly pass strings for container ID and sandbox ID
2. make the modifications to have container ID and sandbox ID be explicit types and then
          a. cast sandboxID to be containerID in situations where they can be the same value
          b. have different functionalities depending on whether sandboxID or containerID is is being used

Thank you in advanced for the clarifications and helping me out :)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.katacontainers.io/pipermail/kata-dev/attachments/20190610/6d213700/attachment.html>

More information about the kata-dev mailing list