<html><head></head><body><div class="ydpc3a72150yahoo-style-wrap" style="font-family: times new roman, new york, times, serif; font-size: 16px;"><div></div>
        <div dir="ltr" data-setdir="false"><span style="color: rgb(38, 40, 42); font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">Hi Dmitry,</span></div><div dir="ltr" data-setdir="false"><span style="color: rgb(38, 40, 42); font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">>I don't think the number of nova-compute instances is related to this problem. NC and IC are </span></div><div dir="ltr" data-setdir="false"><span style="color: rgb(38, 40, 42); font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">>balanced independently, every request from Nova is re-balanced again in ironic-api.</span><br></div><div dir="ltr" data-setdir="false"><span style="color: rgb(38, 40, 42); font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">.</span><br></div><div dir="ltr" data-setdir="false"><div dir="ltr" data-setdir="false">Yes, you are correct.  </div><div>Before last week, the only documentation I knew about that
talks about the HA of ICs is this note buried in the installation guide: </div>

<p style="margin-left:30.0pt"><em><span style="font-family:Calibri,sans-serif">As
of the Newton release, it is possible to have multiple nova-compute services
running the ironic virtual driver (in nova) to provide redundancy. Bare metal
nodes are mapped to the services via a hash ring. If a service goes down, the
available bare metal nodes are remapped to different services.</span></em></p>

<p class="ydp3b0e62flast" style="margin-left:30.0pt"><em><span style="font-family:Calibri,sans-serif">Once
active, a node will stay mapped to the same nova-compute even when it goes
down. The node is unable to be managed through the Compute API until the
service responsible returns to an active state.</span></em></p>

<p class="ydp3b0e62fMsoNormal">Reading that, I always assumed that the mapping of <em><span style="font-family:Calibri,sans-serif">nodes <-> ICs</span></em> was handled
by one of the two services that run on each IC: <em><span style="font-family:Calibri,sans-serif">openstack-nova-compute</span></em> or <em><span style="font-family:Calibri,sans-serif">openstack-ironic-conductor</span></em>.<br>
<br>
But the presentation of this bug didn't make sense under that assumption. We
would see provisions that would have some steps on the correct IC, and some on
a different IC. Completely odd that somehow some steps would happen on a
different IC if that mapping is <em><span style="font-family:Calibri,sans-serif">on</span></em>
an IC...<br>
<br>
Doing some more digging, I found the following in the Ironic developer
documentation (emphasis mine): </p>

<p style="margin-left:30.0pt"><em><span style="font-family:Calibri,sans-serif">Each
Conductor registers itself in the database upon start-up, and periodically
updates the timestamp of its record. Contained within this registration is a
list of the drivers which this Conductor instance supports. This allows all
services to maintain a consistent view of which Conductors and which drivers
are available at all times.</span></em></p>

<p style="margin-left:30.0pt"><em><span style="font-family:Calibri,sans-serif">Based
on their respective driver, all nodes are mapped across the set of available
Conductors using a <a href="https://docs.openstack.org/tooz/latest/user/tutorial/hashring.html" rel="nofollow" target="_blank">consistent
hashing algorithm</a>. </span></em><strong><i><span style="font-family:Calibri,sans-serif">Node-specific
tasks are dispatched from the API tier to the appropriate conductor using
conductor-specific RPC channels.</span></i></strong><em><span style="font-family:Calibri,sans-serif"> As Conductor instances join or leave the cluster, nodes
may be remapped to different Conductors, thus triggering various driver actions
such as take-over or clean-up.</span></em></p>

<span style="font-size:11.0pt;font-family:Calibri,sans-serif;mso-fareast-font-family:Calibri;mso-fareast-theme-font:minor-latin;mso-ansi-language:EN-US;mso-fareast-language:EN-US;mso-bidi-language:AR-SA">It turns out that the <em>openstack-api-service </em>that
runs on the CPNs is actually in charge of the <em>nodes <-> IC</em> mapping. If you hit an
Ironic API service with a IC request (like rebooting a node), the API service places
a message into (what it thinks is) the controlling IC's bucket in RabbitMQ.<br>
<!--[if !supportLineBreakNewLine]--><br>
<!--[endif]--></span></div><div dir="ltr" data-setdir="false"><span style="color: rgb(38, 40, 42); font-family: Helvetica Neue, Helvetica, Arial, sans-serif;"><span><div><div><br></div><div>>This is certainly concerning. When adding IC, do you wait for nodes to rebalance (it may take minutes)?</div><div dir="ltr" data-setdir="false">I did but the nodes were not balancing.  </div></div><div dir="ltr" data-setdir="false">What I thought was a race condition was actually the result of the hash ring being corrupted in one or more of the CPNs running ironic-api.</div><div dir="ltr" data-setdir="false"><br></div></span><span><span style="font-size:11.0pt;font-family:Calibri,sans-serif;mso-fareast-font-family:Calibri;mso-fareast-theme-font:minor-latin;mso-ansi-language:EN-US;mso-fareast-language:EN-US;mso-bidi-language:AR-SA">Once I realized how
it works, and was able to find the bad API server -- I just restarted all 3 API
services (one-by-one, by disabling the restarting member in the SLB to not
receive traffic).<br>
<!--[if !supportLineBreakNewLine]--><br>
<!--[endif]--></span></span>Things seems stable again for now.</span></div><div dir="ltr" data-setdir="false"><span style="color: rgb(38, 40, 42); font-family: Helvetica Neue, Helvetica, Arial, sans-serif;"><br></span></div><div dir="ltr" data-setdir="false"><span style="color: rgb(38, 40, 42); font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">Fred.</span></div><div dir="ltr" data-setdir="false"><span style="color: rgb(38, 40, 42); font-family: Helvetica Neue, Helvetica, Arial, sans-serif;"><br></span></div><div dir="ltr" data-setdir="false"><span style="color: rgb(38, 40, 42); font-family: Helvetica Neue, Helvetica, Arial, sans-serif;"><br></span></div><div dir="ltr" data-setdir="false"><span style="color: rgb(38, 40, 42); font-family: Helvetica Neue, Helvetica, Arial, sans-serif;"><br></span></div>
        
        </div><div id="ydpc3d1f29byahoo_quoted_8625985623" class="ydpc3d1f29byahoo_quoted">
            <div style="font-family:'Helvetica Neue', Helvetica, Arial, sans-serif;font-size:13px;color:#26282a;">
                
                <div>
                    On Monday, April 27, 2020, 08:52:13 AM PDT, Dmitry Tantsur <dtantsur@redhat.com> wrote:
                </div>
                <div><br></div>
                <div><br></div>
                <div><div id="ydpc3d1f29byiv4345689821"><div><div dir="ltr"><div dir="ltr">Hi,<br clear="none"></div><br clear="none"><div class="ydpc3d1f29byiv4345689821gmail_quote"><div class="ydpc3d1f29byiv4345689821gmail_attr" dir="ltr">On Wed, Apr 22, 2020 at 5:59 PM <a shape="rect" href="mailto:fsbiz@yahoo.com" rel="nofollow" target="_blank">fsbiz@yahoo.com</a> <<a shape="rect" href="mailto:fsbiz@yahoo.com" rel="nofollow" target="_blank">fsbiz@yahoo.com</a>> wrote:<br clear="none"></div><blockquote class="ydpc3d1f29byiv4345689821gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex;"><div><div style="font-family:times new roman, new york, times, serif;font-size:16px;"><div></div>
        <div dir="ltr">Hi Arne,</div><div dir="ltr"><br clear="none"></div><div dir="ltr">Thanks for responding.  </div><div dir="ltr">Yes, it is definitely an issue with the hash ring.</div><div dir="ltr"><br clear="none"></div><div dir="ltr">With Queens:</div><div dir="ltr">With 3 NCs and 3 ICs we are relatively stable.</div><div dir="ltr"><br clear="none"></div><div dir="ltr">With 6 NCs/6ICs,  it becomes pretty much unusable.  There seems to be a race condition where 2 NCs</div><div dir="ltr">are competing with each other to get hold of the provisioning. </div></div></div></blockquote><div><br clear="none"></div><div>I don't think the number of nova-compute instances is related to this problem. NC and IC are balanced independently, every request from Nova is re-balanced again in ironic-api.<br clear="none"></div><div> </div><blockquote class="ydpc3d1f29byiv4345689821gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex;"><div><div style="font-family:times new roman, new york, times, serif;font-size:16px;"><div dir="ltr">  A few transitions are</div><div dir="ltr">handled by one IC,  then when another NC takes over some transitions are handled by its IC.</div><div dir="ltr">So we end up in scenarios where the image download happens one one IC but due to the competing</div><div dir="ltr">NCs another IC is entrusted with doing the ISCSI transfer down to the node.  And the provision </div><div dir="ltr">fails because the image cannot be found.</div></div></div></blockquote><div><br clear="none"></div><div>This is certainly concerning. When adding IC, do you wait for nodes to rebalance (it may take minutes)?</div><div><br clear="none"></div><div>Dmitry<div class="ydpc3d1f29byiv4345689821yqt9485222841" id="ydpc3d1f29byiv4345689821yqtfd76609"><br clear="none"></div></div><div class="ydpc3d1f29byiv4345689821yqt9485222841" id="ydpc3d1f29byiv4345689821yqtfd63020"><div> </div><blockquote class="ydpc3d1f29byiv4345689821gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex;"><div><div style="font-family:times new roman, new york, times, serif;font-size:16px;"><div dir="ltr"><br clear="none"></div><div dir="ltr">Appreciate your quick response.</div><div dir="ltr"><br clear="none"></div><div dir="ltr">Regards,</div><div dir="ltr">Fred.</div><div><br clear="none"></div>
        
        </div><div id="ydpc3d1f29byiv4345689821gmail-m_222189157651801389ydp1bda8e09yahoo_quoted_8047352530">
            <div>
                
                <div>
                    On Wednesday, April 22, 2020, 12:41:44 AM PDT, Arne Wiebalck <<a shape="rect" href="mailto:arne.wiebalck@cern.ch" rel="nofollow" target="_blank">arne.wiebalck@cern.ch</a>> wrote:
                </div>
                <div><br clear="none"></div>
                <div><br clear="none"></div>
                <div><div dir="ltr">Hi Fred,<br clear="none"><br clear="none">For quite a while we ran with 3 ICs and 1 NC to manage ~5000 nodes.<br clear="none"><br clear="none">Since this brings some scaling issues with resource tracking, we have<br clear="none">started to split things into conductor groups. Currently, we are at 6<br clear="none">ICs and 3 NCs, but the plan is to have 10 ICs with 10 NCs managing<br clear="none">groups of ~500 nodes.<br clear="none"><br clear="none">The ICs and the NCs will basically be mapped 1:1, rather than having<br clear="none">all NCs see all ICs. The reason is that in the past we saw issues with<br clear="none">the hash ring when the nodes were visible to all NCs, e.g. multiple<br clear="none">NCs were claiming overlapping set of nodes ... having multiple ICs per<br clear="none">group is not an issue, though.<br clear="none"><br clear="none">We are currently still on Stein, but it could well be that you hit this<br clear="none">issue as when you add more NCs, the nodes will be reshuffled.<br clear="none"><br clear="none">Cheers,<br clear="none">  Arne<br clear="none"><div id="ydpc3d1f29byiv4345689821gmail-m_222189157651801389ydp1bda8e09yqtfd73636"><br clear="none">On 22.04.20 00:32, <a shape="rect" href="mailto:fsbiz@yahoo.com" rel="nofollow" target="_blank">fsbiz@yahoo.com</a> wrote:<br clear="none">> Hi folks,<br clear="none">> <br clear="none">> We are seeing some weird issues with multiple compute nodes and would <br clear="none">> appreciate your thoughts.<br clear="none">> <br clear="none">> Background:<br clear="none">> We are on stable Queens.<br clear="none">> As part of an upgrade to accomodate 3X more servers, we decided to add <br clear="none">> three more compute nodes<br clear="none">> + three more ICs for a total of 6 compute nodes and 6 ICs.<br clear="none">> As soon as we added these in preparation for the 3X increase in servers <br clear="none">> I am seeing weird<br clear="none">> behaviour.<br clear="none">> <br clear="none">> A general question to everyone:<br clear="none">> How many of you run your baremetal clouds with 5+ computes and ICs?<br clear="none">> Are things stable with the setup ?<br clear="none">> <br clear="none">> Logs and Analysis:<br clear="none">> all compute and conductor services are up and running.<br clear="none">> <br clear="none">> 1) Baremetal node  c1bda753-d46c-4379-8d07-7787c2a4a7f2 mapped to <br clear="none">> sc-ironic08<br clear="none">> <a shape="rect" href="mailto:root@stg-cl1-dev-001" rel="nofollow" target="_blank">root@stg-cl1-dev-001</a>:~# openstack hypervisor show  <br clear="none">> c1bda753-d46c-4379-8d07-7787c2a4a7f2 | grep ironic<br clear="none">>           |<br clear="none">> | service_host         | <a shape="rect" href="http://sc-ironic08.nvc.nvidia.com" rel="nofollow" target="_blank">sc-ironic08.nvc.nvidia.com</a><br clear="none">> <br clear="none">> 2)Mac address is 6c:b3:11:4f:8a:c0<br clear="none">> <a shape="rect" href="mailto:root@stg-cl1-dev-001" rel="nofollow" target="_blank">root@stg-cl1-dev-001</a>:~# openstack baremetal port list --node <br clear="none">> c1bda753-d46c-4379-8d07-7787c2a4a7f2<br clear="none">> +--------------------------------------+-------------------+<br clear="none">> | UUID                                 | Address           |<br clear="none">> +--------------------------------------+-------------------+<br clear="none">> | a517fb41-f977-438d-8c0d-21046e2918d9 | 6c:b3:11:4f:8a:c0 |<br clear="none">> +--------------------------------------+-------------------+<br clear="none">> <br clear="none">> <br clear="none">> <br clear="none">> <br clear="none">> 2)Provisioning starts:<br clear="none">> <br clear="none">> ironic06 receives the VIF update:  WHY ?<br clear="none">> 2020-04-21 15:05:47.509 71431 INFO ironic.conductor.manager VIF <br clear="none">> 657fea31-3218-4f10-b6ad-8b6a0fa7bab8 successfully attached to node <br clear="none">> c1bda753-d46c-4379-8d07-7787c2a4a7f2<br clear="none">> <br clear="none">> ironic08 (correct one) also receives updates.<br clear="none">> [<a shape="rect" href="mailto:root@sc-ironic08" rel="nofollow" target="_blank">root@sc-ironic08</a> master_images]# tail -f <br clear="none">> /var/log/ironic/ironic-conductor.log | grep <br clear="none">> c1bda753-d46c-4379-8d07-7787c2a4a7f2<br clear="none">> 2020-04-21 15:08:04.943 27542 INFO ironic.conductor.task_manager <br clear="none">> [req-259b0175-65bc-4707-8c88-a65189a29954 - - - - -] Node <br clear="none">> c1bda753-d46c-4379-8d07-7787c2a4a7f2 moved to provision state <br clear="none">> "deploying" from state "wait call-back"; target provision state is "active"<br clear="none">> <br clear="none">> <br clear="none">> For now we have backed down to 3 and are stable again but I would really <br clear="none">> like to overprovision our computes and conductors if possible.<br clear="none">> <br clear="none">> Please let me know your thoughts and if anything rings a bell.<br clear="none">> <br clear="none">> thanks,<br clear="none">> Fred.<br clear="none">> <br clear="none">> <br clear="none">> <br clear="none"><br clear="none"></div></div></div>
            </div>
        </div></div></blockquote></div></div></div></div></div></div>
            </div>
        </div></body></html>