[openstack-dev] [Neutron] Removing ml2_type_vxlan.vxlan_group parameter?
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 , 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? 
> > Main question:
> > There is a patch out to make lb using this ml2 parameter and deprecate
> > the agent one.  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).
> >  https://review.openstack.org/254318
> >  https://review.openstack.org/35384
> >  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
More information about the OpenStack-dev