<div dir="ltr"><div><div><div><div>Hi, <br><br></div>I did some investigation last week, why this was happening before I file the bug. Here are my observations and I would like to work on it. Any guidance is appreciated.<br><br><br></div><div>Upgrade procedure:<br></div>In my setup I have openstack controller on one node, neutron on another node and rest of the nodes are computes. Assume they are running juno. As the first step, <br>a) Bringup up a new openstack node in kilo<br></div><div>b) Migrate database from juno to kilo.<br></div><div>c) Run xxx manage db sync commands.<br></div><div>d) Set upgrade levels to juno <br>e) Migrate neutron and computes to the newer controller.<br></div><div><br></div><div>second step.<br></div><div>a) Upgrade neutron, and then start compute upgrades one at a time.<br><br></div><div>third step,<br></div><div>a) Finalize the upgrade by clearing upgrade levels and restarting services.<br></div><div>b) Issue migrate flavor data command.<br><br></div><div>This procedure is openstack side by side upgraded and neutron and computes inplace upgraded.<br><br></div><div>Issue:<br></div><div>VMs spawned after step1 and during step2 are not flavor migrated. So, migration to liberty was failing.<br><br></div>Investigation:<br></div><div>flavor migrate command filters instance uuids in nova.instance_extra table whose 'flavor' column is NULL and fill in with the necessary flavor information and delete those respective rows from the nova.instance_system_metadata associated with that VM.<br></div><div>For the VMs spawned after the first step and before step2, this flavor information in nova.instance_extra and also respective flavor information in nova.instance_system_metadata table. <br></div><div>Since the filter looks for 'flavor ' column as NULL, these instances are not caught to delete entries in nova.instance_system_metadata. And presence of this data is failing nova db sync while migrating to liberty.<br></div><div><br></div>Possible Solutions:<br><div><div>I feel we should broaden the filter so that instances spawned after step1 and during step 2 are also accounted for data translation. As a quick verification, I tried this by having no filer and it worked. I know filter give efficiency, but would it matter in this context or should we broaden the filter?<br><br></div><div>Please let me know if I am going in the right direction.<br><br></div><div>thanks<br></div><div><br><br></div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 1, 2016 at 10:28 AM, Matt Riedemann <span dir="ltr"><<a href="mailto:mriedem@linux.vnet.ibm.com" target="_blank">mriedem@linux.vnet.ibm.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 9/1/2016 12:05 PM, Suresh Vinapamula wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
On 8/31/2016 4:17 PM, Dan Smith wrote:<br>
<br>
Thanks Dan for your response. While I do run that before I start my<br>
move to liberty, what I see is that it doesn't seem to flavor migrate<br>
meta data for the VMs that are spawned after controller upgrade from<br>
juno to kilo and before all computes upgraded from juno to kilo. The<br>
current work around is to delete those VMs that are spawned after<br>
controller upgrade and before all computes upgrade, and then initiate<br>
liberty upgrade. Then it works fine.<br>
<br>
I can't think of any reason why that would be, or why it would be a<br>
problem. Instances created after the controllers are upgraded should not<br>
have old-style flavor info, so they need not be touched by the migration<br>
code.<br>
<br>
Maybe filing a bug is in order describing what you see?<br>
<br>
--Dan<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">openstack-dev-requ...@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br></span>
<<a href="http://openstack-dev-requ." rel="noreferrer" target="_blank">http://openstack-dev-requ.</a>..@<a href="http://lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank"><wbr>lists.openstack.org?subject:un<wbr>subscribe</a>><span class=""><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
<br>
Also, are you running with the latest kilo patch update? There were<br>
some bug fixes backported after the release from what I remember.<br>
<br>
--<br>
<br>
Thanks,<br>
<br>
Matt Riedemann<br>
<br>
Hi Matt,<br>
<br>
Thanks for the response. I am currently using 2015.1.2. From the release notes of 2015.1.4 <a href="https://wiki.openstack.org/wiki/ReleaseNotes/2015.1.4" rel="noreferrer" target="_blank">https://wiki.openstack.org/wik<wbr>i/ReleaseNotes/2015.1.4</a>, I can't correlate any fixes with this issue. Am I missing something?<br>
<br>
thanks<br>
<br>
Suresh<br>
<br>
</span></blockquote>
<br>
The things I was looking for look like they are in 2015.1.2 so you should be OK there for at least known issues.<span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
<br>
Thanks,<br>
<br>
Matt Riedemann<br>
<br>
</font></span></blockquote></div><br></div>