Open Stack

On Fri, Jun 22, 2018 at 2:53 AM, Boeuf, Sebastien
<sebastien.boeuf at intel.com> wrote:
> Hi folks,
>
> This morning we wanted to release 1.0.1 but held on because of some
> discussions about the semver semantic not being followed with this 1.0.1
> version.
> The problem here, we have some "sort of" backward compatibility breakage
> between the runtime and the agent. And for any non compatible release,
> semver suggest that the new release should bump to the next X version (based
> on X.Y.Z notation).
>
> But before we can answer this, we have to figure out what is that we
> consider a "breakage".
>
> Let me try to explain the different possibility here, starting from an
> environment where you installed Kata 1.0.0 from packages:
>
> First, let's say we introduced a new PauseContainer() command to our agent
> protocol, this command will have one commit on the agent repo, updating the
> gRPC protocol and implementing the new feature. This will be followed by a
> new patch on the runtime to use this new feature, which means we'll have to
> revendor the new protocol and implement the runtime to rely on it.
>
> Now, let's say we bump both runtime and agent repos including those patches
> to the version 1.0.1, here is the issue we will run into:
> - The user with Kata 1.0.0 already installed on his system might update the
> kata-runtime package without updating the VM image containing the agent. And
> from his perspective, this is fine because he knows about semver semantics
> and thinks that a kata-runtime 1.0.1 might still work with the VM image
> container a kata-agent 1.0.0. Unfortunately, this won't work because the
> kata-runtime will try to call into the new command PauseContainer() that had
> been introduced, but the agent will have no idea about what this is, and the
> gRPC will return an error saying this is not a supported/known command.
>
> I have a second example, sorry this email is getting long but we have to
> talk about all cases here... Let's get back to 1.0.0 and say that some
> changes on both kata-runtime and kata-agent are modifying an existing
> command CreateContainer(). In this case, this is a more logical breakage
> since moving one or the other component to the newest version without
> bumping the other (either kata-runtime 1.0.0 and kata-agent 1.0.1, or
> kata-runtime 1.0.1 and kata-agent 1.0.0), will end up in functional issues.
>
> The second example is what I would call an obvious backward compatibility
> breakage, but the first one looks still valid to be taken into account.
>
> So now, to summarize, we have to agree on what we call a non compatible
> version that will be translated into a bump to the next X version.
> And I can see happening a lot of breakage in the future if we include both
> cases in what is considered as a "breakage", meaning we might end up on
> version 100.y.z pretty quickly.
>
If we follow the general guide of adding new grpc fields but do not
change or delete existing ones [1], we can be sure that v1.0.0 runtime
works with the new v1.0.x agent.

OTOH, with any agent protocol extension (new fields or new RPC
requests), we cannot guarantee that the new v1.0.x runtime works with
v1.0.0 agent, because the runtime will send RPC requests containing
newly added fields/RPCs.

So the question is what kind of compatibility we are looking at here?
1). old runtime + new agent
2). new runtime + old agent

If we want to keep both 1 and 2, I think we will have to bump up the
major release version number every time we change the agent protocol.

If we just want to keep 1, most agent protocol change will not break
it as long as we do not change or delete existing fields.

I am fine with either one but we need to get consensus about the kind
of compatibility we want to maintain and stick to it.

ref:
[1] https://developers.google.com/protocol-buffers/docs/overview

Cheers,
Tao

-- 
bergwolf at hyper.sh