<div dir="ltr"><div>Hello:</div><div><br></div><div>I'll approve [1]<span lang="en"><span><span> although I see no need</span></span></span> <span></span>for it. Having "<span id="m_-2598562209509150214gmail-output">resource_provider_hypervisors", there is no need for a second configuration parameter to provide the same information, regardless of the comfort of providing one single string and not a list of tuples.</span></div><div><span id="m_-2598562209509150214gmail-output"><br></span></div><div><span id="m_-2598562209509150214gmail-output">Regards.<br></span></div><div><br></div><div>[1]<a href="https://review.opendev.org/c/openstack/neutron/+/763563" target="_blank">https://review.opendev.org/c/openstack/neutron/+/763563</a></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jun 11, 2021 at 5:51 PM Takashi Kajinami <<a href="mailto:tkajinam@redhat.com" target="_blank">tkajinam@redhat.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">On Fri, Jun 11, 2021 at 8:48 PM Oliver Walsh <<a href="mailto:owalsh@redhat.com" target="_blank">owalsh@redhat.com</a>> wrote:<br></div><div class="gmail_quote"><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 dir="ltr">Hi Takashi,</div><div dir="ltr"><br></div><div>On Thu, 10 Jun 2021 at 15:06, Takashi Kajinami <<a href="mailto:tkajinam@redhat.com" target="_blank">tkajinam@redhat.com</a>> wrote:<br></div></div><div class="gmail_quote"><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">Hi All,<br><br><br><div>I've been working on bug 1926693[1], and am lost about the reasonable</div><div>solutions we expect. Ideally I'd need to bring this topic in the team meeting</div><div>but because of the timezone gap and complicated background, I'd like to</div><div>gather some feedback in ml first.<br></div><br>[1] <a href="https://bugs.launchpad.net/neutron/+bug/1926693" target="_blank">https://bugs.launchpad.net/neutron/+bug/1926693</a><br><br>TL;DR<br> Which one(or ones) would be reasonable solutions for this issue ?<br> (1) <a href="https://review.opendev.org/c/openstack/neutron/+/763563" target="_blank">https://review.opendev.org/c/openstack/neutron/+/763563</a><br> (2) <a href="https://review.opendev.org/c/openstack/neutron/+/788893" target="_blank">https://review.opendev.org/c/openstack/neutron/+/788893</a><br> (3) Implement something different<br><br><div>The issue I reported in the bug is that there is an inconsistency between</div><div>nova and neutron about the way to determine a hypervisor name.</div><div>Currently neutron uses socket.gethostname() (which always returns shortname)</div></div></blockquote><div><br></div><div><div>socket.gethostname() can return fqdn or shortname - <a href="https://docs.python.org/3/library/socket.html#socket.gethostname" target="_blank">https://docs.python.org/3/library/socket.html#socket.gethostname</a>.</div></div></div></div></blockquote><div>You are correct and my statement was not accurate.<br></div><div>So socket.gethostname() returns what is returned by gethostname system call,</div><div>and gethostname/sethostname accept both FQDN and short name, socket.gethostname()</div><div>can return one of FQDN or short name.</div><div><br></div><div>However the root problem is that this logic is not completely same as the ones used</div><div>in each virt driver. Of cause we can require people the "correct" format usage for</div><div>canonical name as well as "hostname", but fixthing this problem in neutron would</div><div>be much more helpful considering the effect caused by enforcing users to "fix"</div><div>hostname/canonical name formatting at this point.<br></div></div><div class="gmail_quote"><div> </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 class="gmail_quote"><div>I've seen cases where it switched from short to fqdn but I'm not sure of the root cause - DHCP lease setting a hostname/domainname perhaps.</div><div><div><div><br></div><div>Thanks,</div><div>Ollie</div></div></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>to determine a hypervisor name to search the corresponding resource provider.<br></div><div>On the other hand, nova uses libvirt's getHostname function (if libvirt driver is used)</div><div>which returns a canonical name. Canonical name can be shortname or FQDN (*1)</div><div>and if FQDN is used then neutron and nova never agree.</div><div><br></div><div>(*1)</div><div><div>IMO this is likely to happen in real deployments. For example, TripelO uses</div><div>FQDN for canonical names. </div></div></div></blockquote><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"><br>Neutron already provides the resource_provider_defauly_hypervisors option<br>to override a hypervisor name used. However because this option accepts<br>a map between interface and hypervisor, setting this parameter requires<br>very redundant description especially when a compute node has multiple<br>interfaces/bridges. The following example shows how redundant the current<br>requirement is.<br>~~~<br>[OVS]<br>resource_provider_bandwidths=br-data1:1024:1024,br-data2:1024:1024,\<br>br-data3:1024,1024,br-data4,1024:1024<br>resource_provider_hypervisors=br-data1:compute0.mydomain,br-data2:\<br>compute0.mydomain,br-data3:compute0.mydomain,br-data4:compute0.mydomain<br>~~~<br><br>I've submitted a change to propose a new single parameter to override<br>the base hypervisor name but this is currently -2ed, mainly because<br>I lacked analysis about the root cause of mismatch when I proposed this.<br> (1) <a href="https://review.opendev.org/c/openstack/neutron/+/763563" target="_blank">https://review.opendev.org/c/openstack/neutron/+/763563</a><br><br><br>On the other hand, I submitted a different change to neutron which implements<br>the logic to get a hypervisor name which is fully compatible with libvirt.<br>While this would save users from even overriding hypervisor names, I'm aware<br>that this might break the other virt driver which depends on a different logic<br>to generate a hypervisor name. IMO the patch is still useful considering<br>the libvirt driver would be the most popular option now, but I'm not fully<br>aware of the impact on the other drivers, especially because I don't know<br>which virt driver would support the minimum QoS feature now.<br> (2) <a href="https://review.opendev.org/c/openstack/neutron/+/788893/" target="_blank">https://review.opendev.org/c/openstack/neutron/+/788893/</a><br><br><br>In the review of (2), Sean mentioned implementing a logic to determine<br>an appropriate resource provider(3) even if there is a mismatch about<br>host name format, but I'm not sure how I would implement that, tbh.<br><br><br><div>My current thought is to merge (1) as a quick solution first, and discuss whether</div><div>we should merge (2), but I'd like to ask for some feedback about this plan</div><div>(like we should NOT merge (2)).<br></div><br><div>I'd appreciate your thoughts about this $topic.</div><div><br></div><div>Thank you,</div><div>Takashi<br></div></div>
</blockquote></div></div>
</blockquote></div></div>
</blockquote></div>