Open Stack

Hello:

I'll approve [1] although I see no need for it. Having
"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.

Regards.

[1]https://review.opendev.org/c/openstack/neutron/+/763563

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

> On Fri, Jun 11, 2021 at 8:48 PM Oliver Walsh <owalsh at redhat.com> wrote:
>
>> Hi Takashi,
>>
>> On Thu, 10 Jun 2021 at 15:06, 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)
>>>
>>
>> socket.gethostname() can return fqdn or shortname -
>> https://docs.python.org/3/library/socket.html#socket.gethostname.
>>
> You are correct and my statement was not accurate.
> So socket.gethostname() returns what is returned by gethostname system
> call,
> and gethostname/sethostname accept both FQDN and short name,
> socket.gethostname()
> can return one of FQDN or short name.
>
> However the root problem is that this logic is not completely same as the
> ones used
> in each virt driver. Of cause we can require people the "correct" format
> usage for
> canonical name as well as "hostname", but fixthing this problem in neutron
> would
> be much more helpful considering the effect caused by enforcing users to
> "fix"
> hostname/canonical name formatting at this point.
>
>
>> 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.
>>
>> Thanks,
>> Ollie
>>
>> 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
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20210614/5b707952/attachment.html>