Open Stack

zhangwei (CR) wrote:
> To summarize:
> 1) We  already break the backward compatibility, and we will break a lot more in near future definitely.  Actually in Vancouver, the participants all agree that we can't promise the API won't be broken and current API isn't a stable version.
> 2) Before we claim that kata can support "live ugrade" and kata is real production ready, I'm fine with the breakage and also fine with 1.0.1 or 1.1.0, maybe latter one looks better.
> 3) After we claim that kata can support "live upgrade" in future, we should reject any modifications which will break the running workloads, unless this is really inevitable, by then, we need to upgrade kata version from x.0.0 to y.0.0.
> But I hope our kata developers can understand what a disaster this could be to a cloud provider like us :-(, and I hope this will never happen.
> 4) Better document that we don't support "live upgrade" yet, and tell users that if you want to upgrade to this new kata-containers version, you must stop all you running kata containers, or there will be anticipated issues.

That summary sounds in line with what Jon said... the protocol between 
the runtime and the agent is not (yet) part of the external contract for 
Kata. Once it is (be it by supporting live upgrade or other explicit 
documentation that you support mixing versions between agent and 
runtime) then you should avoid breaking that altogether (and bump X 
number in the case you really need to).

In example 1 from Sebastien (PauseContainer()), I would still recommend 
you bump Y though, and make it 1.1.0. You're adding a feature and 
modifying the protocol. I would keep .Z bumps for basic bugfixes that do 
not introduce incompatible protocol changes at all, if only to develop 
user confidence that those .Z bumps can be deployed with limited risk.

-- 
Thierry Carrez (ttx)