Open Stack

This option is used to configure a global multicast group IP for VXLAN
networks.
The Cisco Nexus1000V mech driver uses the IP address from this config
option when creating a VXLAN network in multicast mode.

If this config option has an empty value, it is interpreted as selecting
unicast mode for VXLAN networks.

Thanks,
Sourabh

On Wed, Jan 20, 2016 at 5:29 AM, Andreas Scheuring <
scheuran at linux.vnet.ibm.com> wrote:

> 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
>
>
> __________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160120/da6ba379/attachment.html>