Re: [neutron][nova][placement] bug 1926693: What would be the reasonable solution ?

11 Jun 2021


      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).

On Fri, Jun 11, 2021 at 10:36 AM Slawek Kaplonski <skaplons@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@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