Open Stack

Hello:

I think I'm not explaining myself correctly. This is what I'm proposing: to
provide a "hypervisor_type" variable in Neutron and implement, for each
supported hypervisor, a hostname method retrieval.

If we don't support the hypervisor used, the user can always provide the
hostname via "resource_provider_hypervisors".

Regards.

On Fri, Jun 11, 2021 at 12:20 PM Takashi Kajinami <tkajinam at redhat.com>
wrote:

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