<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<br>
<div class="moz-cite-prefix">On 8/26/15 4:47 AM, Grasza, Grzegorz
wrote:<br>
</div>
<blockquote
cite="mid:7E538144DE4CBA4F90EADD7012DDA3C8167EF878@IRSMSX101.ger.corp.intel.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style><!--
/* Font Definitions */
@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;}
/* 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-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;}
@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">Hi,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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></p>
<p class="MsoNormal"><a moz-do-not-send="true"
href="https://github.com/openstack/nova/commit/ad6051bb5c2b62a0de6708cd2d7ac1e3cfd8f1d3#diff-7c6fefb09f0e1b446141d4c8f1ac5458L27">https://github.com/openstack/nova/commit/ad6051bb5c2b62a0de6708cd2d7ac1e3cfd8f1d3#diff-7c6fefb09f0e1b446141d4c8f1ac5458L27</a><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">If yes, I think core reviewers should start
checking for these incompatible changes.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">To clarify, rolling upgrades means support
for running magnum services at different versions at the same
time.<o:p></o:p></p>
<p class="MsoNormal">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></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I can report bugs and propose patches with
version changes for this release, to get the effort started.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">In Mitaka, when Grenade gets multi-node
support, it can be used to add CI tests for rolling upgrades
in Magnum.</p>
</div>
</blockquote>
<br>
from my POV I don't have strong feelings about using versioned
objects early, however I do feel that the actual database migration
model itself should *not* rely on expand/contract early in a
project's lifecycle; expand/contract places severe limitations on
the kinds of changes that can easily be made to a database schema
and is better applied once the schema is mostly solidified in
overall form, and the only changes that continue to be made are
simple additions of new tables, columns and indexes.<br>
<br>
<br>
<br>
<br>
<blockquote
cite="mid:7E538144DE4CBA4F90EADD7012DDA3C8167EF878@IRSMSX101.ger.corp.intel.com"
type="cite">
<div class="WordSection1">
<p class="MsoNormal"><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">/ Greg<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></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>
</body>
</html>