<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:SimSun;
panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:"\@SimSun";
panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
color:black;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";
color:black;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";
color:black;}
span.EmailStyle17
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:windowtext;}
span.EmailStyle18
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;
color:black;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";
color:black;}
span.EmailStyle23
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body bgcolor="white" lang="EN-CA" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal"><span style="color:#1F497D">Ryan,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Thanks for sharing your inputs. By looking through your response, I couldn’t find the reasoning about why a young project is the perfect time to enforce a strict object version rule. I think a young project often
starts with a static (or non-frequently changing) version until a point in time the project reaches a certain level of maturity. Isn’t it? As a core reviewer of Magnum, I observe that the project is under fast development and objects are changing from time
to time. It is very heavy to do all the work for strictly enforcing the version (bump version number, document the changed fields, re-generate the hashes, implement the compatibility check, etc.). Instead, I would prefer to let all objects stay in a beta version,
until a time in future, the team decides to start bumping it.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Best regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Hongbin<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext">From:</span></b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext"> Ryan Rossiter [mailto:rlrossit@linux.vnet.ibm.com]
<br>
<b>Sent:</b> August-27-15 2:41 PM<br>
<b>To:</b> openstack-dev@lists.openstack.org<br>
<b>Subject:</b> Re: [openstack-dev] [magnum] versioned objects changes<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:10.0pt">If you want my inexperienced opinion, a young project is the perfect time to start this. Nova has had a bunch of problems with versioned objects that don't get realized until the
next release (because that's the point in time at which grenade (or worse, operators) catch this). At that point, you then need to hack things around and backport them in order to get them working in the old branch. [1] is an excellent example of Nova having
to backport a fix to an object because we weren't using strict object testing.<br>
<br>
I don't feel that this should be adding overhead to contributors and reviewers. With [2], this test absolutely helps both contributors and reviewers. Yes, it requires "fixing" things when a change happens to an object. Learning to do this "fix" to update object
hashes is extremely easy to do and I hope my updated comment on there makes it even easier (also be aware I am new to OpenStack & Nova as of about 2 months ago, so this stuff was new to me too not very long ago).<br>
<br>
I understand that something like [2] will cause a test to fail when you make a major change to a versioned object. But you *want* that. It helps reviewers more easily catch contributors to say "You need to update the version, because the hash changed". The
sooner you start using versioned objects in the way they are designed, the smaller the upfront cost, and it will also be a major savings later on if something like [1] pops up.<br>
<br>
[1]: <a href="https://bugs.launchpad.net/nova/+bug/1474074">https://bugs.launchpad.net/nova/+bug/1474074</a><br>
[2]: <a href="https://review.openstack.org/#/c/217342/">https://review.openstack.org/#/c/217342/</a></span><o:p></o:p></p>
<div>
<p class="MsoNormal">On 8/27/2015 9:46 AM, Hongbin Lu wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span style="color:#1F497D">-1 from me.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">IMHO, the rolling upgrade feature makes sense for a mature project (like Nova), but not for a young project like Magnum. It incurs overheads for contributors & reviewers to check the object compatibility in each
patch. As you mentioned, the key benefit of this feature is supporting different version of magnum components running at the same time (i.e. running magnum-api 1.0 with magnum-conductor 1.1). I don’t think supporting this advanced use case is a must at the
current stage.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">However, I don’t mean to against merging patches of this feature. I just disagree to enforce the rule of object version change in the near future.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">Best regards,</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">Hongbin</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Grasza, Grzegorz [<a href="mailto:grzegorz.grasza@intel.com">mailto:grzegorz.grasza@intel.com</a>]
<br>
<b>Sent:</b> August-26-15 4:47 AM<br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
<b>Subject:</b> [openstack-dev] [magnum] versioned objects changes</span><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US">Hi,</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US">I noticed that right now, when we make changes (adding/removing fields) in
<a href="https://github.com/openstack/magnum/tree/master/magnum/objects">https://github.com/openstack/magnum/tree/master/magnum/objects</a> , we don't change object versions.</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US">The idea of objects is that each change in their fields should be versioned, documentation about the change should also be written in a comment inside the object and the obj_make_compatible method should be implemented
or updated. See an example here:</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US"><a href="https://github.com/openstack/nova/commit/ad6051bb5c2b62a0de6708cd2d7ac1e3cfd8f1d3#diff-7c6fefb09f0e1b446141d4c8f1ac5458L27">https://github.com/openstack/nova/commit/ad6051bb5c2b62a0de6708cd2d7ac1e3cfd8f1d3#diff-7c6fefb09f0e1b446141d4c8f1ac5458L27</a></span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US">The question is, do you think magnum should support rolling upgrades from next release or maybe it's still too early?</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US">If yes, I think core reviewers should start checking for these incompatible changes.</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US">To clarify, rolling upgrades means support for running magnum services at different versions at the same time.</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US">In Nova, there is an RPC call in the conductor to backport objects, which is called when older code gets an object it doesn’t understand. This patch does this in Magnum:
<a href="https://review.openstack.org/#/c/184791/">https://review.openstack.org/#/c/184791/</a> .</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US">I can report bugs and propose patches with version changes for this release, to get the effort started.</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US">In Mitaka, when Grenade gets multi-node support, it can be used to add CI tests for rolling upgrades in Magnum.</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US">/ Greg</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman","serif""><br>
<br>
<br>
<o:p></o:p></span></p>
<pre>__________________________________________________________________________<o:p></o:p></pre>
<pre>OpenStack Development Mailing List (not for usage questions)<o:p></o:p></pre>
<pre>Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><o:p></o:p></pre>
<pre><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><o:p></o:p></pre>
</blockquote>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman","serif""><br>
<br>
<o:p></o:p></span></p>
<pre>-- <o:p></o:p></pre>
<pre>Thanks,<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Ryan Rossiter<o:p></o:p></pre>
</div>
</body>
</html>