<html dir="ltr">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<style>
<!--
@font-face
{font-family:"Cambria Math"}
@font-face
{font-family:Calibri}
@font-face
{font-family:Tahoma}
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif}
a:link, span.MsoHyperlink
{color:blue;
text-decoration:underline}
a:visited, span.MsoHyperlinkFollowed
{color:purple;
text-decoration:underline}
span.EmailStyle17
{font-family:"Calibri",sans-serif;
color:windowtext}
span.msoIns
{text-decoration:underline;
color:teal}
.MsoChpDefault
{font-size:10.0pt}
@page WordSection1
{margin:1.0in 1.0in 1.0in 1.0in}
-->
</style><style type="text/css" id="owaParaStyle">P {margin-top:0;margin-bottom:0;}</style>
</head>
<body fpstyle="1" ocsi="0" link="blue" lang="EN-US" vlink="purple" bgcolor="white">
<div style="direction: ltr;font-family: Tahoma;color: #000000;font-size: 10pt;">My two cents:<br>
<br>
this resembles k8s's kubelet / apiserver versioning.<br>
<br>
a change that can potentially be incompatable is a minor version bump. so say, 1.10 to 1.11.<br>
upgrading kubelet 1.10.1 to 1.10.2 usually doesn't break existing things. at times they have said you must evacuate a node going from 1.x to 1.x+1 though. Which is similar to the use case below. no way to maintain state. They grantee kubelet 1.x will work with
up to apiserver 1.x+2<br>
<br>
So, kata-runtime is similar to the kube-apiserver in this case and the rest is kubelet.<br>
<br>
the vm/agenty things should be able to lag a few versions but until implemented, must match.<br>
<br>
It should probably bump the minor version, as it really is an incompatible version change and not just a bug fix release as 1.0.1 would imply.<br>
<br>
so I'd recommend calling the next version 1.1.0 instead of 1.0.1. And note in the upgrade notes that the node must be drained before upgrading. People might not look for a release note if it was called 1.0.1 as they won't really expect a breaking change in
that case.<br>
<br>
Thanks,<br>
Kevin<br>
<br>
<br>
<div style="font-family: Times New Roman; color: #000000; font-size: 16px">
<hr tabindex="-1">
<div id="divRpF922050" style="direction: ltr;"><font face="Tahoma" size="2" color="#000000"><b>From:</b> Ernst, Eric [eric.ernst@intel.com]<br>
<b>Sent:</b> Thursday, June 21, 2018 3:59 PM<br>
<b>To:</b> Jon Olson; Boeuf, Sebastien<br>
<b>Cc:</b> kata-dev@lists.katacontainers.io<br>
<b>Subject:</b> Re: [kata-dev] What to do about release versioning ?<br>
</font><br>
</div>
<div></div>
<div>
<div class="WordSection1">
<p class="MsoNormal">I agree on this stance, Jon. Perhaps until we have the protocol/API defined and versioned this shouldn’t be necessary.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Stepping back, I think it makes more sense to fix the bugs existing (which I think are quite troubling) and documenting expectations of tags/packages rather than holding off releases. I do acknowledge I often like to break the rules, and
think this is such a scenario.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Bottom line, for many reasons we need to very well define the protocol and version it (this is not done yet), and I expect there will be changes that continue in this space until we have the major use cases of Frakti/Huawei figured out.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Eric</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal"> </p>
<p class="MsoNormal"> </p>
<div style="border:none; border-top:solid #B5C4DF 1.0pt; padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-left:.5in"><b><span style="font-size:12.0pt; color:black">From:
</span></b><span style="font-size:12.0pt; color:black">Jon Olson via kata-dev <kata-dev@lists.katacontainers.io><br>
<b>Reply-To: </b>Jon Olson <jonolson@google.com><br>
<b>Date: </b>Thursday, June 21, 2018 at 12:06 PM<br>
<b>To: </b>"Boeuf, Sebastien" <sebastien.boeuf@intel.com><br>
<b>Cc: </b>"kata-dev@lists.katacontainers.io" <kata-dev@lists.katacontainers.io><br>
<b>Subject: </b>Re: [kata-dev] What to do about release versioning ?</span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> </p>
</div>
<div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:12.0pt">This came up in Vancouver, but I know not everyone had the opportunity to be there. Here were/are my thoughts drawing from my experience working on similar problems for GCE VMs: currently
iiuc (until in-place-upgrade and downgrade of releases is supported) the runtime and the guest image (including agent) are all part of the "release artifacts". I would argue that the protocol between the runtime and the agent is not (yet) part of the external
contract for Kata. It probably should be, but until that protocol is itself formally documented and versioned I would say you have only changed internal contracts between components that are part of the same atomic set of release artifacts.</span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:12.0pt"> </span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:12.0pt">I do think it's valuable to make the agent protocol part of the external contract for Kata, but I think that requires the protocol itself be explicitly versioned[0].</span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:12.0pt"> </span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:12.0pt">Jon</span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:12.0pt"> </span></p>
</div>
<div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:12.0pt">[0]: I also still have an AI to put together a slide deck on gRPC API evolution best practices to minimize breaking changes generally. I should probably go do that.</span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:12.0pt"> </span></p>
</div>
</div>
</div>
<p class="MsoNormal" style="margin-left:.5in"> </p>
<div>
<div>
<p class="MsoNormal" style="margin-left:.5in">On Thu, Jun 21, 2018 at 11:54 AM Boeuf, Sebastien <<a href="mailto:sebastien.boeuf@intel.com" target="_blank" rel="noopener noreferrer">sebastien.boeuf@intel.com</a>> wrote:</p>
</div>
<blockquote style="border:none; border-left:solid #CCCCCC 1.0pt; padding:0in 0in 0in 6.0pt; margin-left:4.8pt; margin-right:0in">
<div>
<div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt; font-family:"Tahoma",sans-serif; color:black">Hi folks,</span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt; font-family:"Tahoma",sans-serif; color:black"> </span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt; font-family:"Tahoma",sans-serif; color:black">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.</span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt; font-family:"Tahoma",sans-serif; color:black">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).</span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt; font-family:"Tahoma",sans-serif; color:black"> </span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt; font-family:"Tahoma",sans-serif; color:black">But before we can answer this, we have to figure out what is that we consider a "breakage".</span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt; font-family:"Tahoma",sans-serif; color:black"> </span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt; font-family:"Tahoma",sans-serif; color:black">Let me try to explain the different possibility here, starting from an environment where you installed Kata 1.0.0 from packages:</span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt; font-family:"Tahoma",sans-serif; color:black"> </span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt; font-family:"Tahoma",sans-serif; color:black">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.</span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt; font-family:"Tahoma",sans-serif; color:black"> </span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt; font-family:"Tahoma",sans-serif; color:black">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:</span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt; font-family:"Tahoma",sans-serif; color:black">- 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.</span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt; font-family:"Tahoma",sans-serif; color:black"> </span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt; font-family:"Tahoma",sans-serif; color:black">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.</span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt; font-family:"Tahoma",sans-serif; color:black"> </span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt; font-family:"Tahoma",sans-serif; color:black">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.</span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt; font-family:"Tahoma",sans-serif; color:black"> </span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt; font-family:"Tahoma",sans-serif; color:black">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.</span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt; font-family:"Tahoma",sans-serif; color:black">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.</span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt; font-family:"Tahoma",sans-serif; color:black"> </span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt; font-family:"Tahoma",sans-serif; color:black">Numbers are cheap, but here is the status and I/we need some feedback before we can push the pending release (as we don't want to introduce
a wrong version number in the history).</span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt; font-family:"Tahoma",sans-serif; color:black"> </span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt; font-family:"Tahoma",sans-serif; color:black">Thanks,</span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt; font-family:"Tahoma",sans-serif; color:black">Sebastien</span></p>
</div>
</div>
</div>
<p class="MsoNormal" style="margin-left:.5in">_______________________________________________<br>
kata-dev mailing list<br>
<a href="mailto:kata-dev@lists.katacontainers.io" target="_blank" rel="noopener noreferrer">kata-dev@lists.katacontainers.io</a><br>
<a href="http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev" target="_blank" rel="noopener noreferrer">http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev</a></p>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</body>
</html>