Currently, the gRPC protocol version between components (particularly the runtime and agent) must match to guarantee correct operation.

Scenarios (aka compatability challenges)

The two main scenarios we need to consider from a compatability perspective are:

• new runtime, old agent

  The runtime is using a newer gRPC protocol version than the agent.

  Current behaviour:

  If this happens today, the agent will crash. For example, if you currently install the packaged version of Kata, then upgrade the runtime, the following error will occur:

  $ sudo docker run -ti --runtime kata-runtime busybox shdocker: Error response from daemon: OCI 
  runtime create failed: rpc error: code = InvalidArgument desc = Unknown storage driver "ephemeral": unknown.   
  

  This occurs because the runtime is using a new gRPC feature (ephemeral volume support) and although that support is also in the agent, the 1.0.0 version of the kata-containers-image package contains an older agent that does not have such support.

• old runtime, new agent

  The agent is using a newer gRPC protocol version than the runtime.

  Current behaviour:

  This may result in a crash but depends on what the protocol changes are. If new verbs have been added, this should be a NOP. However, if changes to the existing protocol have been made, the agent will likely crash.

Guarantees

• We need to be able to guarantee that if the agent is using a newer protocol version than the runtime, the system will remain operable. It would seem this is only possible if the agent (or the gRPC package) is able to consume all previous protocol versions?)

/cc @jon

TODO

We need to find a way to make the agent resilient to handling "old" protocol requests.

Related:

• handling changes to the agent's gRPC protocol buffer protocol version kata-containers#17.
• Document all protocol elements #150.