← Back to team overview

yahoo-eng-team team mailing list archive

[Bug 1926693] Re: Logic to obtain hypervisor hostname is not completely compatible with libvirt

 

Reviewed:  https://review.opendev.org/c/openstack/neutron/+/788893
Committed: https://opendev.org/openstack/neutron/commit/577217c52d677ba35ca78b87c06302d506f66ff9
Submitter: "Zuul (22348)"
Branch:    master

commit 577217c52d677ba35ca78b87c06302d506f66ff9
Author: Takashi Kajinami <tkajinam@xxxxxxxxxx>
Date:   Fri Apr 30 15:12:04 2021 +0900

    Make default hypervisor hostname compatible with libvirt
    
    This change ensures that neutron relies on the same logic as libvirt
    to generate hypervisor hostname, to fix imcompatible hostname format
    used in Nova and Neutron for resource provider name in some
    configuration pattens like the one generated by TripleO.
    
    Closes-Bug: #1926693
    Change-Id: Iea2533f4c52935b4ecda9ec22fb619c131febfa1


** Changed in: neutron
       Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1926693

Title:
  Logic to obtain hypervisor hostname is not completely compatible with
  libvirt

Status in neutron:
  Fix Released

Bug description:
  Currently neutron uses socket.getshostname() to determine a heyervisor
  hostname assuming that is what is used in libvirt.

  However libvirt actually relies on the following steps to generate
  hypervisor hostname and socket.gethostname() doesn't match in some
  cases.

  /* Who knew getting a hostname could be so delicate.  In Linux (and Unices
   * in general), many things depend on "hostname" returning a value that will
   * resolve one way or another.  In the modern world where networks frequently
   * come and go this is often being hard-coded to resolve to "localhost".  If
   * it *doesn't* resolve to localhost, then we would prefer to have the FQDN.
   * That leads us to 3 possibilities:
   *
   * 1)  gethostname() returns an FQDN (not localhost) - we return the string
   *     as-is, it's all of the information we want
   * 2)  gethostname() returns "localhost" - we return localhost; doing further
   *     work to try to resolve it is pointless
   * 3)  gethostname() returns a shortened hostname - in this case, we want to
   *     try to resolve this to a fully-qualified name.  Therefore we pass it
   *     to getaddrinfo().  There are two possible responses:
   *     a)  getaddrinfo() resolves to a FQDN - return the FQDN
   *     b)  getaddrinfo() fails or resolves to localhost - in this case, the
   *         data we got from gethostname() is actually more useful than what
   *         we got from getaddrinfo().  Return the value from gethostname()
   *         and hope for the best.
   */

  https://github.com/libvirt/libvirt/blob/ec2e3336b8c8df572600043976e1ab5feead656e/src/util/virutil.c#L454-L531

  Acutally we do see that in TripleO deployment socket.gethostname() and virsh hostname don't agree, and this causes an issue when we set up resource_provider_bandwidths
  ~~~
  [heat-admin@compute-0 ~]$ python
  Python 3.6.8 (default, Dec  5 2019, 15:45:45)
  [GCC 8.3.1 20191121 (Red Hat 8.3.1-5)] on linux
  Type "help", "copyright", "credits" or "license" for more information.
  >>> import socket
  >>> socket.gethostname()
  'compute-0'
  >>> exit()
  [heat-admin@compute-0 ~]$ sudo podman exec -it nova_libvirt virsh hostname
  compute-0.redhat.local
  ~~~

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1926693/+subscriptions


References