Open Stack

On 11 March 2015 at 10:56, Matt Riedemann <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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150311/7c8dbb2a/attachment.html>