[openstack-dev] [Neutron] Removing ml2_type_vxlan.vxlan_group parameter?

Andreas Scheuring scheuran at linux.vnet.ibm.com
Wed Jan 20 13:29:16 UTC 2016


I agree, I would vote for killing ml2 option, too!

I wanted to reach out via the ML to find potential users of it or to
clarify why it has been added at all!

-- 
-----
Andreas (IRC: scheuran) 

On Mi, 2016-01-20 at 10:11 +0100, Ihar Hrachyshka wrote:
> Andreas Scheuring <scheuran at linux.vnet.ibm.com> wrote:
> 
> > There was some discussion if the ml2_type_vxlan.vxlan_group of the ml2
> > config file (Neutron Server) can be removed [1], as it is not being used
> > by in-tree drivers (ovs, lb, sriov).
> >
> > OVS: does not support vxlan mcast
> > LB: uses it's own agent configuration today.
> > SRIOV: does not support vxlan at all
> >
> >
> > - Does anybody know any out-of-tree ml2 drivers that take use of this
> > option?
> > - Why was it added at all? [2]
> >
> >
> > Main question:
> > There is a patch out to make lb using this ml2 parameter and deprecate
> > the agent one. [3] Is this the right approach, or can we keep the agent
> > parameter and remove the server one (which is not used - or where we
> > don't know the users)?
> >
> 
> As I commented in gerrit, agents are not supposed to load ml2 config files,  
> so if that’s the approach you suggest, I don’t think it’s the right one.  
> Though if we talk about server passing the value into agents by some other  
> means, like AMQP, then yes, it could be a reasonable approach.
> 
> I would vote for killing ml2 option, but your concern about out-of-tree  
> patches that can rely on the option is legit. Overall, I believe we should  
> stop considering oslo.config options to be part of ml2 driver API. If there  
> is a value for drivers to access some specific ml2 option, it should be  
> exposed through a public getter.
> 
> The problem with enforcing it is that oslo.config CONF object is global, so  
> any driver can always import CONF from oslo.config. Well, I don’t mind if  
> we break an out-of-tree driver as long as properly communicate it for a  
> while that config options should not be accessed directly (and as long as  
> we provide means to retrieve needed values in other way).
> 
> >
> >
> > [1] https://review.openstack.org/254318
> > [2] https://review.openstack.org/35384
> > [3] https://review.openstack.org/#/c/268153
> >
> >
> >
> > -- 
> > -----
> > Andreas (IRC: scheuran)
> >
> >
> >
> > __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




More information about the OpenStack-dev mailing list