Bug 1308979

From my perspective this isn't strictly a bug, seeing as how the code is doing what it's supposed to be doing (Grab the first IP address on a CIDR for a router interface). We can modify the behavior to grab the first *available* address, but seeing as you can ask for a specific IP address when you attach a router to an interface, a workaround is readily available, and so the impact of this issue is low.

(In reply to Alex Stellwag from comment #0)
> Description of problem:
> 
> When a router interface is created, neutron always tries to assign the first
> available IP address and fails if it is already in use
> 
> Version-Release number of selected component (if applicable):
> 
> openstack-neutron.noarch     2015.1.2-6.el7ost
> 
> How reproducible:
> 
> 100%
> 
> Steps to Reproduce:
> 1. create two networks
> 2. create a router w/o external network and give it an interface in each of
> the (internal) networks just created
> 3. create a second router (w/ external gateway)
> 4. give that second router an interface in one of the internal networks
> 
> Actual results:
> 
> The interface creation fails with (i.e.) "Address 172.16.0.1 is already in
> use"
> 
> Expected results:
> 
> Interface is properly created
> 
> Additional info:
> 
> The interface can be created by manually specifying an unused address but it
> should work automatically.

I understand the bug and why it happens. I can't say I understand the rationale or use case for solving it. Looking at the steps for reproduction, can you explain why that is useful?

You have R1 connected to N1 and N2, and R2 connected only to N2 and an external network. What's the use case here?

(In reply to Assaf Muller from comment #3)
> I understand the bug and why it happens. I can't say I understand the
> rationale or use case for solving it. Looking at the steps for reproduction,
> can you explain why that is useful?
> 
> You have R1 connected to N1 and N2, and R2 connected only to N2 and an
> external network. What's the use case here?

There are regulations that require the DB to be on a separate network from the webserver for example (the regulations usually refers to 3 layers but two are as good for this discussion).

there is no reason for the DB to be connected to the external network but the webserver does need to be connected.

VM1 (DB) on N1
VM2 (webserver) on N2

you need VM1 to be reachable from VM2
you need external connectivity to VM2

[...]

> 
> There are regulations that require the DB to be on a separate network from
> the webserver for example (the regulations usually refers to 3 layers but
> two are as good for this discussion).
> 
> there is no reason for the DB to be connected to the external network but
> the webserver does need to be connected.
> 
> VM1 (DB) on N1
> VM2 (webserver) on N2
> 
> you need VM1 to be reachable from VM2
> you need external connectivity to VM2

Understood. The use case can be satisfied by specifying the IP address the 2nd router should use. It can also be specified via a single router and security groups.

Since Neutron does allow you to specify the address of a router interface, I'm closing this RFE.