Open Stack

+1 on 1.1.0.

Live-upgrade is nice, but lots of people are starting to do more immutable
infrastructure. Bring up new workloads on a brand new server/cluster with a
newer version. Just need to document that 1.1.0 is not compatible with
1.0.0.

We see something similar with K8s and Mesos. It's pretty common with
projects with a fast release cycle.

We are running K8s 1.4.x and the latest is 1.11.x. We are not even thinking
about upgrading from 1.4.x to 1.11.x, we are just saying let's create a new
cluster and move all the workloads gradually. Also, 1.11.x comes a brand
new set of container runtimes.

With Mesos, we are doing the same, upgrading from 1.3.0 to 1.6.0
by creating a new cluster.

Cheers.



On Fri, Jun 22, 2018 at 6:13 AM, Hunt, James O <james.o.hunt at intel.com>
wrote:

> 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.
>
> _______________________________________________
> kata-dev mailing list
> kata-dev at lists.katacontainers.io
> http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.katacontainers.io/pipermail/kata-dev/attachments/20180622/30451d65/attachment-0001.html>