<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<font size="-1">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 class="moz-txt-link-freetext" href="https://bugs.launchpad.net/nova/+bug/1474074">https://bugs.launchpad.net/nova/+bug/1474074</a><br>
[2]: <a class="moz-txt-link-freetext" href="https://review.openstack.org/#/c/217342/">https://review.openstack.org/#/c/217342/</a><br>
</font><br>
<div class="moz-cite-prefix">On 8/27/2015 9:46 AM, Hongbin Lu wrote:<br>
</div>
<blockquote
cite="mid:0957CD8F4B55C0418161614FEC580D6BCCB235@SZXEMI503-MBS.china.huawei.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<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:SimSun;
panose-1:2 1 6 0 3 1 1 1 1 1;}
@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;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
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;}
span.EmailStyle17
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:windowtext;}
span.EmailStyle18
{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]-->
<div class="WordSection1">
<p class="MsoNormal"><span style="color:#1F497D">-1 from me.<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">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.<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">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.<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
style="font-size:10.0pt;font-family:"Tahoma","sans-serif""
lang="EN-US">From:</span></b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif""
lang="EN-US"> Grasza, Grzegorz
[<a class="moz-txt-link-freetext" 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<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span lang="EN-US">Hi,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">I noticed that right
now, when we make changes (adding/removing fields) in
<a moz-do-not-send="true"
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.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></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:<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><a
moz-do-not-send="true"
href="https://github.com/openstack/nova/commit/ad6051bb5c2b62a0de6708cd2d7ac1e3cfd8f1d3#diff-7c6fefb09f0e1b446141d4c8f1ac5458L27"><a class="moz-txt-link-freetext" href="https://github.com/openstack/nova/commit/ad6051bb5c2b62a0de6708cd2d7ac1e3cfd8f1d3#diff-7c6fefb09f0e1b446141d4c8f1ac5458L27">https://github.com/openstack/nova/commit/ad6051bb5c2b62a0de6708cd2d7ac1e3cfd8f1d3#diff-7c6fefb09f0e1b446141d4c8f1ac5458L27</a></a><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></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?<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">If yes, I think core
reviewers should start checking for these incompatible
changes.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></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.<o:p></o:p></span></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 moz-do-not-send="true"
href="https://review.openstack.org/#/c/184791/">https://review.openstack.org/#/c/184791/</a>
.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></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.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></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.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">/ Greg<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Thanks,
Ryan Rossiter</pre>
</body>
</html>