Open Stack

In short, +1 to the above ideas. I think 1.1.0 looks a better choice now. And
we'd better have a branch for the bug fixes releases of each feature release,
such as branch 1.0.y.
I offline discussed with @bergwolf and @WeiZhang555. To make things simple:
- The major version change, 1.x to 2.x should include significant feature
update, or introduce significant changes for the users. The current situation is
not such a big change definitely.- The minor version change, let me talk it
later because it is the current debating point.- The bug fix number, such as
1.0.x to 1.0.y, should only include bug fix or security fix, which should not
break main data structures, interfaces, and wire protocol.
As the protobuf definition had been changed, bump version to 1.1.0 is almost
what we have to do.
Then we should could define things like the following:
- Any feature update that introduce interface or protobuf definition change  -
should not be put into "stable release branch vM.n.y", and should be merged to
master.  - should be labeled as "feature update" or similar label, and be listed
in the release note later.- We checkpoint the master to make a new stable
release tag 'vM.(n+1).0' and branch 'vM.(n+1).y' at the release date, and make
packages.
- Xu  





On Sat, Jun 23, 2018 12:59 AM, Ricardo Aravena raravena80 at gmail.com  wrote:
+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
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




--
Xu WangCTO & Cofounder, Hypergithub/twitter/wechat: @gnawuxhttp://hyper.sh
Hyper_: Make VM run like container
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.katacontainers.io/pipermail/kata-dev/attachments/20180623/6d01fc7c/attachment.html>