Open Stack

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[1] to provide new config option as it's now and additionally implement https://
review.opendev.org/c/openstack/neutron/+/788893[2] 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.
> > 
> > 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20210611/56c24b3c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20210611/56c24b3c/attachment.sig>