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

Ihar Hrachyshka ihrachys at redhat.com
Wed Jan 20 09:11:49 UTC 2016

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

More information about the OpenStack-dev mailing list