Can't specify gateway when creating subnet with subnetpool and without cidr

Bug #1518819 reported by Hong Hui Xiao on 2015-11-23
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
neutron
Wishlist
Unassigned

Bug Description

When creating a subnet by using the subnetpool(without specifying cidr), I can't specify the gateway. Either using --no-gateway or --gateway, the newly created subnet will have the first ip in the pool as the the gateway ip.
Looks like the code don't consider gateway ip at [1], and always set the first ip in pool as gateway ip in [2].

I fount this when creating an external network, which don't have a gateway indeed. The unnecessary gateway ip will create meaningless default route in router.

[1] https://github.com/openstack/neutron/blob/master/neutron/ipam/requests.py#L290
[2] https://github.com/openstack/neutron/blob/master/neutron/ipam/subnet_alloc.py#L126

Hong Hui Xiao (xiaohhui) on 2015-11-23
Changed in neutron:
assignee: nobody → Hong Hui Xiao (xiaohhui)
Hong Hui Xiao (xiaohhui) on 2015-11-23
summary: - Can't specify gateway when creating subnet with subnetpool
+ Can't specify gateway when creating subnet with subnetpool and without
+ cidr
Gary Kotton (garyk) on 2015-11-23
tags: added: api
Changed in neutron:
importance: Undecided → Medium
status: New → Confirmed
tags: added: l3-dvr-backlog
Carl Baldwin (carl-baldwin) wrote :

I don't think I have any links to share about this but there was a lot of discussion on this in the blueprint spec and possibly the ML. The discussion was centered around how does one specify such a gateway? You don't know the network address of the subnet so you can't specify the gateway address.

In some versions of the spec, I had proposed that the gateway address and allocation pools could be specified by using 0 as the network address. For example, you'd specify 0.0.0.0.3 if you wanted to use the third address in the resulting. So, if the subnet ended up being 192.168.0.128/25 then your gateway would end up being 192.168.0.131. There were objections to using the gateway field for this because it would be somewhat non-RESTful to return a different gateway than the one in the request. I then proposed using a new input-only field called gateway_template or something.

In the end, a few people argued that if you don't care what the subnet is then why would you care what gateway address or allocation pool you get in the subnet? We settled on not allowing you to specify the gateway address in this use case.

Changed in neutron:
status: Confirmed → Incomplete
importance: Medium → Wishlist
Hong Hui Xiao (xiaohhui) wrote :

Hi Carl.
Thanks for the explanation. I understand the point in your comment, and now I see why the spec says that user might "using 0 as a wildcard prefix " at [1]. However, in the real neutron, I have to specify the exact cidr and allocation pool, even if I have used a subnetpool.

My concern in this bug is that when user create a subnet from subnetpool. And the user don't want the gateway ip. Now there are 2 ways: a) specify the exact cidr and then the --no-gateway will take effect. b) create the subnet from subnetpool, and then update the subnet with --no-gateway.

I think neutron can at least open the gate for --no-gateway + auto allocation subnetpool. Yes, I don't care what the subnet is, and I don't care what the gateway ip is. I just don't want the gateway ip. What is your opinion about it?

[1] https://specs.openstack.org/openstack/neutron-specs/specs/kilo/subnet-allocation.html

Carl Baldwin (carl-baldwin) wrote :

Thanks for the reply. I think enabling the --no-gateway use case could be worth pursuing. I'm happy to leave this bug as triaged. I don't have any plans to work on this at the moment but someone (you, maybe) could pick it up.

Changed in neutron:
status: Incomplete → Confirmed

Fix proposed to branch: master
Review: https://review.openstack.org/251758

Changed in neutron:
status: Confirmed → In Progress

Change abandoned by Hong Hui Xiao (<email address hidden>) on branch: master
Review: https://review.openstack.org/251758
Reason: This patch doesn't draw much attention, and fails the jenkins.

This bug is > 180 days without activity. We are unsetting assignee and milestone and setting status to Incomplete in order to allow its expiry in 60 days.

If the bug is still valid, then update the bug status.

Changed in neutron:
assignee: Hong Hui Xiao (xiaohhui) → nobody
status: In Progress → Incomplete
Launchpad Janitor (janitor) wrote :

[Expired for neutron because there has been no activity for 60 days.]

Changed in neutron:
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers