<div dir="ltr"><div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Wed, Oct 17, 2018 at 4:46 PM Ignazio Cassano <<a href="mailto:ignaziocassano@gmail.com">ignaziocassano@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div>Hello, here the select you suggested:</div><div><br></div><div>MariaDB [nova]> select * from shadow_services;<br>Empty set (0,00 sec)<br><br>MariaDB [nova]> select * from shadow_compute_nodes;<br>Empty set (0,00 sec)</div><div><br></div><div>As far as the upgrade tooling is concerned, we are using only yum update on old compute nodes to have same packages installed on the new compute-nodes</div></div></div></blockquote><div><br></div><div><br></div><div>Well, to be honest, I was looking at some other bug for OSP <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1636463">https://bugzilla.redhat.com/show_bug.cgi?id=1636463</a> which is pretty identical so you're not alone :-)</div><div>For some reason, yum update modifies something in the DB that I don't know yet. Which exact packages are you using ? RDO ones ?</div><div><br></div><div>I marked the downstream bug as NOTABUG since I wasn't able to reproduce it and given I also provided a SQL query for fixing it, but maybe we should try to see which specific package has a problem...</div><div><br></div><div>-Sylvain<br></div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div><div>Procedure used</div><div>We have an openstack with 3 compute nodes : podto1-kvm01, podto1-kvm02, podto1-kvm03<br></div><div>1) install a new compute node (podto1-kvm04)<br></div><div>2) On controller we discovered the new compute node: su -s /bin/sh -c "nova-manage cell_v2 discover_hosts --verbose" nova</div><div>3) Evacuate podto1-kvm01</div><div>4) yum update on podto1-kvm01 and reboot it<br></div><div>5) Evacuate podto1-kvm02 <br></div><div>6) yum update on podto1-kvm02 and reboot it<br></div><div>7) Evacuate podto1-kvm03 <br></div><div>8) yum update podto1-kvm03 and reboot it</div><div><br></div></div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr">Il giorno mer 17 ott 2018 alle ore 16:37 Matt Riedemann <<a href="mailto:mriedemos@gmail.com" target="_blank">mriedemos@gmail.com</a>> ha scritto:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 10/17/2018 9:13 AM, Ignazio Cassano wrote:<br>
> Hello Sylvain, here the output of some selects:<br>
> MariaDB [nova]> select host,hypervisor_hostname from compute_nodes;<br>
> +--------------+---------------------+<br>
> | host         | hypervisor_hostname |<br>
> +--------------+---------------------+<br>
> | podto1-kvm01 | podto1-kvm01        |<br>
> | podto1-kvm02 | podto1-kvm02        |<br>
> | podto1-kvm03 | podto1-kvm03        |<br>
> | podto1-kvm04 | podto1-kvm04        |<br>
> | podto1-kvm05 | podto1-kvm05        |<br>
> +--------------+---------------------+<br>
> <br>
> MariaDB [nova]> select host from compute_nodes where host='podto1-kvm01' <br>
> and hypervisor_hostname='podto1-kvm01';<br>
> +--------------+<br>
> | host         |<br>
> +--------------+<br>
> | podto1-kvm01 |<br>
> +--------------+<br>
<br>
Does your upgrade tooling run a db archive/purge at all? It's possible <br>
that the actual services table record was deleted via the os-services <br>
REST API for some reason, which would delete the compute_nodes table <br>
record, and then a restart of the nova-compute process would recreate <br>
the services and compute_nodes table records, but with a new compute <br>
node uuid and thus a new resource provider.<br>
<br>
Maybe query your shadow_services and shadow_compute_nodes tables for <br>
"podto1-kvm01" and see if a record existed at one point, was deleted and <br>
then archived to the shadow tables.<br>
<br>
-- <br>
<br>
Thanks,<br>
<br>
Matt<br>
<br>
_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
</blockquote></div>
_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
</blockquote></div></div></div>