[openstack-dev] [nova][neutron][nfv] is there any reason neutron.allow_duplicate_networks should not be True by default?
Matt Riedemann
mriedem at linux.vnet.ibm.com
Thu Mar 12 14:27:08 UTC 2015
On 3/11/2015 7:23 PM, Ian Wells wrote:
> On 11 March 2015 at 10:56, Matt Riedemann <mriedem at linux.vnet.ibm.com
> <mailto:mriedem at linux.vnet.ibm.com>> wrote:
>
> While looking at some other problems yesterday [1][2] I stumbled
> across this feature change in Juno [3] which adds a config option
> "allow_duplicate_networks" to the [neutron] group in nova. The
> default value is False, but according to the spec [4] neutron allows
> this and it's just exposing a feature available in neutron via nova
> when creating an instance (create the instance with 2 ports from the
> same network).
>
> My question then is why do we have a config option to toggle a
> feature that is already supported in neutron and is really just
> turning a failure case into a success case, which is generally
> considered OK by our API change guidelines [5].
>
> I'm wondering if there is anything about this use case that breaks
> other NFV use cases, maybe something with SR-IOV / PCI? If not, I
> plan on pushing a change to deprecate the option in Kilo and remove
> it in Liberty with the default being to allow the operation.
>
>
> This was all down to backward compatibility.
>
> Nova didn't allow two interfaces on the same Neutron network. We tried
> to change this by filing a bug, and the patches got rejected because the
> original behaviour was claimed to be intentional and desirable. (It's
> not clear that it was intentional behaviour because it was never
> documented, but the same lack of documented intent meant it's also not
> clear it was a bug, so the situation was ambiguous.)
>
> Eventually it was fixed as new functionality using a spec [1] so that
> the change and reasoning could be clearly described, and because of the
> previous concerns, Racha, who implemented the spec, additionally chose
> to use a config item to preserve the original behaviour unless the new
> one was explicitly requested.
> --
> Ian.
>
> [1]
> https://review.openstack.org/#/c/97716/5/specs/juno/nfv-multiple-if-1-net.rst
>
>
> __________________________________________________________________________
> 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
>
For anyone following along, we're deprecating the
allow_duplicated_networks option in Kilo and will remove it in Liberty
(and just make it work like this by default):
https://review.openstack.org/#/c/163581/
--
Thanks,
Matt Riedemann
More information about the OpenStack-dev
mailing list