<div dir="ltr">This option is used to configure a global multicast group IP for VXLAN networks.<div><div>The Cisco Nexus1000V mech driver uses the IP address from this config option when creating a VXLAN network in multicast mode.</div><div><br></div><div>If this config option has an empty value, it is interpreted as selecting unicast mode for VXLAN networks. </div><div><br></div><div><div class="gmail_extra">Thanks,<br>Sourabh</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 20, 2016 at 5:29 AM, Andreas Scheuring <span dir="ltr"><<a href="mailto:scheuran@linux.vnet.ibm.com" target="_blank">scheuran@linux.vnet.ibm.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I agree, I would vote for killing ml2 option, too!<br>
<br>
I wanted to reach out via the ML to find potential users of it or to<br>
clarify why it has been added at all!<br>
<span class="im"><br>
--<br>
-----<br>
Andreas (IRC: scheuran)<br>
<br>
</span><div class=""><div class="h5">On Mi, 2016-01-20 at 10:11 +0100, Ihar Hrachyshka wrote:<br>
> Andreas Scheuring <<a href="mailto:scheuran@linux.vnet.ibm.com">scheuran@linux.vnet.ibm.com</a>> wrote:<br>
><br>
> > There was some discussion if the ml2_type_vxlan.vxlan_group of the ml2<br>
> > config file (Neutron Server) can be removed [1], as it is not being used<br>
> > by in-tree drivers (ovs, lb, sriov).<br>
> ><br>
> > OVS: does not support vxlan mcast<br>
> > LB: uses it's own agent configuration today.<br>
> > SRIOV: does not support vxlan at all<br>
> ><br>
> ><br>
> > - Does anybody know any out-of-tree ml2 drivers that take use of this<br>
> > option?<br>
> > - Why was it added at all? [2]<br>
> ><br>
> ><br>
> > Main question:<br>
> > There is a patch out to make lb using this ml2 parameter and deprecate<br>
> > the agent one. [3] Is this the right approach, or can we keep the agent<br>
> > parameter and remove the server one (which is not used - or where we<br>
> > don't know the users)?<br>
> ><br>
><br>
> As I commented in gerrit, agents are not supposed to load ml2 config files,<br>
> so if that’s the approach you suggest, I don’t think it’s the right one.<br>
> Though if we talk about server passing the value into agents by some other<br>
> means, like AMQP, then yes, it could be a reasonable approach.<br>
><br>
> I would vote for killing ml2 option, but your concern about out-of-tree<br>
> patches that can rely on the option is legit. Overall, I believe we should<br>
> stop considering oslo.config options to be part of ml2 driver API. If there<br>
> is a value for drivers to access some specific ml2 option, it should be<br>
> exposed through a public getter.<br>
><br>
> The problem with enforcing it is that oslo.config CONF object is global, so<br>
> any driver can always import CONF from oslo.config. Well, I don’t mind if<br>
> we break an out-of-tree driver as long as properly communicate it for a<br>
> while that config options should not be accessed directly (and as long as<br>
> we provide means to retrieve needed values in other way).<br>
><br>
> ><br>
> ><br>
> > [1] <a href="https://review.openstack.org/254318" rel="noreferrer" target="_blank">https://review.openstack.org/254318</a><br>
> > [2] <a href="https://review.openstack.org/35384" rel="noreferrer" target="_blank">https://review.openstack.org/35384</a><br>
> > [3] <a href="https://review.openstack.org/#/c/268153" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/268153</a><br>
> ><br>
> ><br>
> ><br>
> > --<br>
> > -----<br>
> > Andreas (IRC: scheuran)<br>
> ><br>
> ><br>
> ><br>
> > __________________________________________________________________________<br>
> > OpenStack Development Mailing List (not for usage questions)<br>
> > Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div></div></div>