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 <scheu...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
