Open Stack

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/20210612/44f0847e/attachment.html>