Open Stack

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 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/f1c80da3/attachment-0001.html>