[Openstack-operators] deprecation of allow_duplicate_networks
salv.orlando at gmail.com
Fri Sep 25 06:43:57 UTC 2015
Good morning Sam,
As you say, your requirement cannot be satisfied today. The option you
mention provided a nice workaround but did not fully solve your problem.
I think in order to satisfy it Neutron could either:
1) Specify this on a per-network setting in Neutron
2) Enable VIF usage tracking grouping it by networks and apply a limit of 1
3) A combination of the previous two where VIF usage limiting is enforce
only on selected networks
I think #2 alone would satisfy your requirement.
On the other you could have also your requirement satisfied by adding
something in nova, but since allow_duplicate_networks is being deprecated
I'm not sure it makes sense to reintroduce something which is semantically
At this stage - since Mitaka dev cycle just started - I would suggest to
file a Neutron RFE bug  if you have not already done so.
On 25 September 2015 at 07:07, Sam Morrison <sorrison at gmail.com> wrote:
> We are in the process of migrating to neutron and have come across this
> handy config option that is sadly being deprecated. (seems to be a theme of
> mine this week)
> Does anyone know if this is supported in some other way?
> We have limited IP addresses and ideally we’d like to prevent users from
> taking more than 1 per instance. I’m wondering if this should be a neutron
> setting and could be set on a per network basis. We’d like to prevent
> duplicates on our public provider networks but don’t care about the private
> tenant networks.
> Anyone got any ideas or know of anything happening in this space?
> help='DEPRECATED: Allow an instance to have multiple vNICs '
> 'attached to the same Neutron network. This option is '
> 'deprecated in the 2015.1 release and will be removed '
> 'in the 2015.2 release where the default behavior will
> 'be to always allow multiple ports from the same
> network '
> 'to be attached to an instance.',
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-operators