Open Stack

Hi,

Dnia piątek, 11 czerwca 2021 13:14:03 CEST Takashi Kajinami pisze:
> Hi Radolfo,
> 
> Thank you for your clarification and sorry I misread what you wrote.
> 
> My concern with that approach is that adding the hypervisor_type parameter
> would mean
> neutron will implement a logic for the other virt drivers, which is
> currently maintained in
> nova or hypervisor like libvirt in the future and it would expand the scope
> of neutron too much.
> 
> IIUC current Neutron doesn't care about virt drivers used, and I agree with
> Slawek that
> it's better to keep that current design here.
> 
> Thank you,
> Takashi
> 
> 
> On Fri, Jun 11, 2021 at 7:39 PM Rodolfo Alonso Hernandez <
> 
> ralonsoh at redhat.com> wrote:
> > Hello:
> > 
> > I think I'm not explaining myself correctly. This is what I'm proposing:
> > to provide a "hypervisor_type" variable in Neutron and implement, for each
> > supported hypervisor, a hostname method retrieval.
> > 
> > If we don't support the hypervisor used, the user can always provide the
> > hostname via "resource_provider_hypervisors".

I'm not sure if adding "hypervisor drivers" to neutron is good idea.
Solution proposed by Takashi is simpler IMHO. If user just want's to override 
hostname for all resources, this new option can be used. But in some case, 
where it's needed to do it "per bridge", that's also possible.
I know it's maybe not perfect but IMO still better than nothing.

> > 
> > Regards.
> > 
> > On Fri, Jun 11, 2021 at 12:20 PM Takashi Kajinami <tkajinam at redhat.com>
> > 
> > wrote:
> >> Hi Slawek and Radolfo,
> >> 
> >> Thank you for your feedback.
> >> 
> >> On Fri, Jun 11, 2021 at 5:47 PM Rodolfo Alonso Hernandez <
> >> 
> >> ralonsoh at redhat.com> wrote:
> >>> 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).
> >> 
> >> The main problem is that the logic to determine "hypervisor name" is
> >> different in each virt driver.
> >> For example libvirt driver uses canonical name while power driver uses
> >> [DEFAULT] host in nova.conf .
> >> So if we fix compatibility with one virt driver then it would break
> >> compatibility with the other driver.
> >> Because neutron is not aware of the virt driver used, it's impossible to
> >> avoid that inconsistency completely.
> >> 
> >> 
> >> Thank you,
> >> Takashi
> >> 
> >>> 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


-- 
Slawek Kaplonski
Principal Software Engineer
Red Hat
-------------- 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/66ce8989/attachment-0001.sig>