First things first: this issue is about the version of the Kata Containers defined agent protocol, not the version of protocol buffers (proto2, proto3, ...) used to define the agent protocol!

Overview

• The agent protocol which underlies Kata is a gRPC protocol buffer based.
• A protocol buffer protocol requires each message member or field to be numbered.
• If the ordering of the message fields in a protocol buffer changes, all components that use the protocol nominally need to be updated to ensure they are all "speaking the same language".

Handling protocol changes

Protocol buffers do have some basic features to handle protocol changes:

• https://developers.google.com/protocol-buffers/docs/proto3#updating
• https://developers.google.com/protocol-buffers/docs/proto3#enum_reserved
• https://developers.google.com/protocol-buffers/docs/proto3#unknowns
• The "deprecated" field option.

Requirements

Since we have made lots of change and will no doubt wish to make changes at some point in the future, we need a documented approach for:

• How to deal with protocol modifications.
• How to test such changes.

Concrete example

Assume we are already creating Kata Containers packages (we're not yet)...

• A new image package is created containing a new agent version which is using a new gRPC protocol version.
• Unless packages for all system components are updated at the same time for this new gRPC protocol version (*), the system will not function correctly.

Implications

This implies:

• We need some sort of "trigger" so that if any of the *.proto files in the directory below change in the master branch:

  • https://github.com/kata-containers/agent/blob/master/protocols/grpc/

  ... that this somehow triggers a re-vendor of the agent code for the other system components.

• We should start looking at the how best to handle protocol changes (see links above).

[*] - This also assumes we aren't using any of the protocol buffer features to handle protocol changes.