<div dir="ltr"><div>Hi Slawek and Radolfo,</div><div><br></div><div>Thank you for your feedback.</div><div><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jun 11, 2021 at 5:47 PM Rodolfo Alonso Hernandez <<a href="mailto:ralonsoh@redhat.com" target="_blank">ralonsoh@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">I agree with this idea but what <a href="https://review.opendev.org/c/openstack/neutron/+/763563" target="_blank">https://review.opendev.org/c/openstack/neutron/+/763563</a> is proposing differs from what I'm saying: instead of providing the hostname (that is something we can do "resource_provider_hypervisors"), we should provide the hypervisor name (default: libvirt).<br></div></blockquote><div><br></div><div>The main problem is that the logic to determine "hypervisor name" is different in each virt driver.</div><div>For example libvirt driver uses canonical name while power driver uses [DEFAULT] host in nova.conf .</div><div>So if we fix compatibility with one virt driver then it would break compatibility with the other driver.</div><div>Because neutron is not aware of the virt driver used, it's impossible to avoid that inconsistency completely.<br></div></div><div><br></div><div><br></div><div>Thank you,</div><div>Takashi<br></div><div class="gmail_quote"><div><br></div><div><br></div><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><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jun 11, 2021 at 10:36 AM Slawek Kaplonski <<a href="mailto:skaplons@redhat.com" target="_blank">skaplons@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><p style="margin:0px">Hi,</p>
<br><p style="margin:0px">Dnia piątek, 11 czerwca 2021 09:57:27 CEST Rodolfo Alonso Hernandez pisze:</p>
<p style="margin:0px">> Hello Takashi and Neutrinos:</p>
<p style="margin:0px">> </p>
<p style="margin:0px">> First of all, thank you for working on this.</p>
<p style="margin:0px">> </p>
<p style="margin:0px">> Currently users have the ability to override the host name using</p>
<p style="margin:0px">> "resource_provider_hypervisors". That means this parameter is always</p>
<p style="margin:0px">> configurable; IMO we are safe on this.</p>
<p style="margin:0px">> </p>
<p style="margin:0px">> The problem we have is how we should retrieve this host name if</p>
<p style="margin:0px">> "resource_provider_hypervisors" is not provided. I think the solution could</p>
<p style="margin:0px">> be a combination of:</p>
<p style="margin:0px">> </p>
<p style="margin:0px">>    - A first patch providing the ability to select the hypervisor type. The</p>
<p style="margin:0px">>    default one could be "libvirt". Each driver can have a particular host name</p>
<p style="margin:0px">>    retrieval implementation. The default one will be the implemented right</p>
<p style="margin:0px">>    now: "socket.gethostname()"</p>
<p style="margin:0px">>    - <a href="https://review.opendev.org/c/openstack/neutron/+/788893" target="_blank">https://review.opendev.org/c/openstack/neutron/+/788893</a>, providing</p>
<p style="margin:0px">>    full compatibility for libvirt.</p>
<p style="margin:0px">> </p>
<p style="margin:0px">> Those are my two cents.</p>
<br><p style="margin:0px">We can move on with the patch <a href="https://review.opendev.org/c/openstack/neutron/+/763563" target="_blank">https://review.opendev.org/c/openstack/neutron/+/763563</a> to provide new config option as it's now and additionally implement <a href="https://review.opendev.org/c/openstack/neutron/+/788893" target="_blank">https://review.opendev.org/c/openstack/neutron/+/788893</a> so users who are using libvirt will not need to change anything, but if someone is using other hypervisor, this will allow adjustments. Wdyt?</p>
<br><p style="margin:0px">> </p>
<p style="margin:0px">> Regards.</p>
<p style="margin:0px">> </p>
<p style="margin:0px">> </p>
<p style="margin:0px">> </p>
<p style="margin:0px">> On Thu, Jun 10, 2021 at 4:12 PM Takashi Kajinami <<a href="mailto:tkajinam@redhat.com" target="_blank">tkajinam@redhat.com</a>></p>
<p style="margin:0px">> </p>
<p style="margin:0px">> wrote:</p>
<p style="margin:0px">> > Hi All,</p>
<p style="margin:0px">> > </p>
<p style="margin:0px">> > </p>
<p style="margin:0px">> > I've been working on bug 1926693[1], and am lost about the reasonable</p>
<p style="margin:0px">> > solutions we expect. Ideally I'd need to bring this topic in the team</p>
<p style="margin:0px">> > meeting</p>
<p style="margin:0px">> > but because of the timezone gap and complicated background, I'd like to</p>
<p style="margin:0px">> > gather some feedback in ml first.</p>
<p style="margin:0px">> > </p>
<p style="margin:0px">> > [1] <a href="https://bugs.launchpad.net/neutron/+bug/1926693" target="_blank">https://bugs.launchpad.net/neutron/+bug/1926693</a></p>
<p style="margin:0px">> > </p>
<p style="margin:0px">> > TL;DR</p>
<p style="margin:0px">> > </p>
<p style="margin:0px">> >  Which one(or ones) would be reasonable solutions for this issue ?</p>
<p style="margin:0px">> >  </p>
<p style="margin:0px">> >   (1) <a href="https://review.opendev.org/c/openstack/neutron/+/763563" target="_blank">https://review.opendev.org/c/openstack/neutron/+/763563</a></p>
<p style="margin:0px">> >   (2) <a href="https://review.opendev.org/c/openstack/neutron/+/788893" target="_blank">https://review.opendev.org/c/openstack/neutron/+/788893</a></p>
<p style="margin:0px">> >   (3) Implement something different</p>
<p style="margin:0px">> > </p>
<p style="margin:0px">> > The issue I reported in the bug is that there is an inconsistency between</p>
<p style="margin:0px">> > nova and neutron about the way to determine a hypervisor name.</p>
<p style="margin:0px">> > Currently neutron uses socket.gethostname() (which always returns</p>
<p style="margin:0px">> > shortname)</p>
<p style="margin:0px">> > to determine a hypervisor name to search the corresponding resource</p>
<p style="margin:0px">> > provider.</p>
<p style="margin:0px">> > On the other hand, nova uses libvirt's getHostname function (if libvirt</p>
<p style="margin:0px">> > driver is used)</p>
<p style="margin:0px">> > which returns a canonical name. Canonical name can be shortname or FQDN</p>
<p style="margin:0px">> > (*1)</p>
<p style="margin:0px">> > and if FQDN is used then neutron and nova never agree.</p>
<p style="margin:0px">> > </p>
<p style="margin:0px">> > (*1)</p>
<p style="margin:0px">> > IMO this is likely to happen in real deployments. For example, TripelO uses</p>
<p style="margin:0px">> > FQDN for canonical names.</p>
<p style="margin:0px">> > </p>
<p style="margin:0px">> > Neutron already provides the resource_provider_defauly_hypervisors option</p>
<p style="margin:0px">> > to override a hypervisor name used. However because this option accepts</p>
<p style="margin:0px">> > a map between interface and hypervisor, setting this parameter requires</p>
<p style="margin:0px">> > very redundant description especially when a compute node has multiple</p>
<p style="margin:0px">> > interfaces/bridges. The following example shows how redundant the current</p>
<p style="margin:0px">> > requirement is.</p>
<p style="margin:0px">> > ~~~</p>
<p style="margin:0px">> > [OVS]</p>
<p style="margin:0px">> > resource_provider_bandwidths=br-data1:1024:1024,br-data2:1024:1024,\</p>
<p style="margin:0px">> > br-data3:1024,1024,br-data4,1024:1024</p>
<p style="margin:0px">> > resource_provider_hypervisors=br-data1:compute0.mydomain,br-data2:\</p>
<p style="margin:0px">> > compute0.mydomain,br-data3:compute0.mydomain,br-data4:compute0.mydomain</p>
<p style="margin:0px">> > ~~~</p>
<p style="margin:0px">> > </p>
<p style="margin:0px">> > I've submitted a change to propose a new single parameter to override</p>
<p style="margin:0px">> > the base hypervisor name but this is currently -2ed, mainly because</p>
<p style="margin:0px">> > I lacked analysis about the root cause of mismatch when I proposed this.</p>
<p style="margin:0px">> > </p>
<p style="margin:0px">> >  (1) <a href="https://review.opendev.org/c/openstack/neutron/+/763563" target="_blank">https://review.opendev.org/c/openstack/neutron/+/763563</a></p>
<p style="margin:0px">> > </p>
<p style="margin:0px">> > On the other hand, I submitted a different change to neutron which</p>
<p style="margin:0px">> > implements</p>
<p style="margin:0px">> > the logic to get a hypervisor name which is fully compatible with libvirt.</p>
<p style="margin:0px">> > While this would save users from even overriding hypervisor names, I'm</p>
<p style="margin:0px">> > aware</p>
<p style="margin:0px">> > that this might break the other virt driver which depends on a different</p>
<p style="margin:0px">> > logic</p>
<p style="margin:0px">> > to generate a hypervisor name. IMO the patch is still useful considering</p>
<p style="margin:0px">> > the libvirt driver would be the most popular option now, but I'm not fully</p>
<p style="margin:0px">> > aware of the impact on the other drivers, especially because I don't know</p>
<p style="margin:0px">> > which virt driver would support the minimum QoS feature now.</p>
<p style="margin:0px">> > </p>
<p style="margin:0px">> >  (2) <a href="https://review.opendev.org/c/openstack/neutron/+/788893/" target="_blank">https://review.opendev.org/c/openstack/neutron/+/788893/</a></p>
<p style="margin:0px">> > </p>
<p style="margin:0px">> > In the review of (2), Sean mentioned implementing a logic to determine</p>
<p style="margin:0px">> > an appropriate resource provider(3) even if there is a mismatch about</p>
<p style="margin:0px">> > host name format, but I'm not sure how I would implement that, tbh.</p>
<p style="margin:0px">> > </p>
<p style="margin:0px">> > </p>
<p style="margin:0px">> > My current thought is to merge (1) as a quick solution first, and discuss</p>
<p style="margin:0px">> > whether</p>
<p style="margin:0px">> > we should merge (2), but I'd like to ask for some feedback about this plan</p>
<p style="margin:0px">> > (like we should NOT merge (2)).</p>
<p style="margin:0px">> > </p>
<p style="margin:0px">> > I'd appreciate your thoughts about this $topic.</p>
<p style="margin:0px">> > </p>
<p style="margin:0px">> > Thank you,</p>
<p style="margin:0px">> > Takashi</p>
<br><br><p style="margin:0px">-- </p>
<p style="margin:0px">Slawek Kaplonski</p>
<p style="margin:0px">Principal Software Engineer</p>
<p style="margin:0px">Red Hat</p>
</div>
</blockquote></div>
</blockquote></div>
</div>