Open Stack

Hi Sebastien,

Thanks very much for kicking off what has turned into a great thread from
the humble beginnings of [1] ;)

I've attempted to summarise it to distill the essence as there is a lot of
detail:

- There seems to be general consensus that:

    - 1.1.0 is better than 2.0.0.
    - 1.1.0 is also better than 1.0.1.

   By changing the minor number users can see it is more than a bugfix
release, but we're arguably abusing the naming slightly by not bumping the
major number.

  That seeming abuse of semver is handled by a "get out of jail free card",
namely that we haven't documented the gRPC protocol and hence implicitly
haven't agreed (and documented) precisely what API breakage means yet.

  We also need to remember to include details of the breakage in the
release notes.

- Plan B:

  It's worth mentioned that another thought we had yesterday was that we
could revert the breaking change [2] to allow us to release a true 1.0.1.
  That would give us breathing space to investigate the breakage more fully
and find a way to avoid it happening in the future (or atleast detect and
minimise).


== TODO list from this thread ==

I've raised a bunch of issues here and referenced some existing ones.
Please dive in by commenting, emojifying, assigning to yourself (please!
;), etc:

- Jon plans to write up a slide deck on gRPC API evolution best practices
(I'd love to see this! ;)

- We need to document the gRPC protocol:

  https://github.com/kata-containers/agent/issues/150

- We need to version the gRPC protocol:

  https://github.com/kata-containers/kata-containers/issues/17
  https://github.com/kata-containers/agent/issues/272

- We need to guarantee persistent state files are consumable by newer
component versions:

  https://github.com/kata-containers/kata-containers/issues/25

- We need to update our documentation to explain that we cannot handle
"live upgrade":

  https://github.com/kata-containers/documentation/issues/178

- We need to update our documentation to explain that all component
versions must (currently) match for correct operation:

  https://github.com/kata-containers/documentation/issues/177

Cheers,

James

[1] - https://github.com/kata-containers/proxy/pull/76
[2] - https://github.com/kata-containers/runtime/pull/357


2018-06-22 10:55 GMT+01:00 Thierry Carrez <thierry at openstack.org>:

> 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)
>
>
> _______________________________________________
> kata-dev mailing list
> kata-dev at lists.katacontainers.io
> http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev
>



-- 
James
---
https://katacontainers.io/ | https://github.com/kata-containers
<https://github.com/clearcontainers>
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3
1RJ.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.katacontainers.io/pipermail/kata-dev/attachments/20180622/668ca528/attachment.html>