The wrong default-prefixlen have not checked, when create a subnetpool

Bug #1644433 reported by wujun on 2016-11-24
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
neutron
Low
Unassigned

Bug Description

In Newton environment.

I create an unreasonable subnetpool, bacause the default-prefixlen(16) is less than the network number(24).But It can be created successfully.

For example:
#neutron subnetpool-create test_subnetpool --pool-prefix 10.0.0.0/24 --default-prefixlen 16
Created a new subnetpool:
+-------------------+--------------------------------------+
| Field | Value |
+-------------------+--------------------------------------+
| address_scope_id | |
| created_at | 2016-11-24T05:26:07Z |
| default_prefixlen | 16 |
| default_quota | |
| description | |
| id | 55931020-fb32-4179-b08a-de2696f098f9 |
| ip_version | 4 |
| is_default | False |
| max_prefixlen | 32 |
| min_prefixlen | 8 |
| name | test_subnetpool |
| prefixes | 10.0.0.0/24 |
| project_id | 4cfa11e3c1064971abebdcfeff82a6ad |
| revision_number | 1 |
| shared | False |
| tenant_id | 4cfa11e3c1064971abebdcfeff82a6ad |
| updated_at | 2016-11-24T05:26:07Z |
+-------------------+--------------------------------------+

When I using the subnetpool, It will be error.

For example:
#neutron net-create demo-net
#neutron subnet-create demo-net --name demo-subnet --subnetpool test_subnetpool
Failed to allocate subnet: Insufficient prefix space to allocate subnet size /16.
Neutron server returns request_ids: ['req-99b5a7be-fbb1-4f00-8a89-5e3b7ce4041c']

I think this subnetpool should not be created successfully in this situation.

wujun (wujun) on 2016-11-24
Changed in neutron:
assignee: nobody → wujun (wujun)
wujun (wujun) on 2016-11-24
description: updated
wujun (wujun) on 2016-11-24
description: updated
John Davidge (john-davidge) wrote :

I see the same behavior you describe. I wonder if there are any legitimate use cases taking advantage of this?

Changed in neutron:
status: New → Confirmed
importance: Undecided → Low

Change abandoned by Armando Migliaccio (<email address hidden>) on branch: master
Review: https://review.openstack.org/405131
Reason: This review is > 4 weeks without comment, and failed Jenkins the last time it was checked. We are abandoning this for now. Feel free to reactivate the review by pressing the restore button and leaving a 'recheck' comment to get fresh test results.

Changed in neutron:
status: Confirmed → Incomplete
assignee: wujun (wujun) → nobody
tags: added: l3-ipam-dhcp low-hanging-fruit
rajiv (rajiv-kumar) on 2017-02-10
Changed in neutron:
assignee: nobody → rajiv (rajiv-kumar)
rajiv (rajiv-kumar) wrote :

I want to take this bug.

Changed in neutron:
status: Incomplete → In Progress

This bug has had a related patch abandoned and has been automatically un-assigned due to inactivity. Please re-assign yourself if you are continuing work or adjust the state as appropriate if it is no longer valid.

Changed in neutron:
assignee: rajiv (rajiv-kumar) → nobody
status: In Progress → New
tags: added: timeout-abandon

Change abandoned by Kevin Benton (<email address hidden>) on branch: master
Review: https://review.openstack.org/405131
Reason: This review is > 4 weeks without comment, and failed Jenkins the last time it was checked. We are abandoning this for now. Feel free to reactivate the review by pressing the restore button and leaving a 'recheck' comment to get fresh test results.

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

Changed in neutron:
assignee: nobody → Reedip (reedip-banerjee)
status: New → In Progress

Change abandoned by Armando Migliaccio (<email address hidden>) on branch: master
Review: https://review.openstack.org/447983
Reason: This review is > 4 weeks without comment, and failed Jenkins the last time it was checked. We are abandoning this for now. Feel free to reactivate the review by pressing the restore button and leaving a 'recheck' comment to get fresh test results.

Changed in neutron:
assignee: Reedip (reedip-banerjee) → Sapna Jadhav (sapana45)
Ryan Tidwell (ryan-tidwell) wrote :

I disagree that this is a bug. This is working as expected. You set a default_prefixlen of 16, and only supplied a /24 to the subnet pool. Under no circumstance would I expect this to work. The prefixlen parameters are independent of what prefixes are available in the subnet pool. I would suggest that the workflow here is simply incorrect. The ability to set the default prefix length and to request a subnet of specific size exist precisely to deal with these scenarios.

I would think about this differently. In this case, I only have a /24 available. It makes no sense to set my default to /16, or even /24 for that matter. The error message is also quite clear in my opinion. I don't see a bug here.

Brian Haley (brian-haley) wrote :

I tend to agree with Ryan, and you can fix the issue with 'openstack subnet pool set --default-prefix-length 28 test_subnetpool' If you had to destroy the pool and re-create it I might think otherwise.

Sapna Jadhav (sapana45) on 2019-09-19
Changed in neutron:
assignee: Sapna Jadhav (sapana45) → nobody

This bug has had a related patch abandoned and has been automatically un-assigned due to inactivity. Please re-assign yourself if you are continuing work or adjust the state as appropriate if it is no longer valid.

Changed in neutron:
status: In Progress → New

Change abandoned by Slawek Kaplonski (<email address hidden>) on branch: master
Review: https://review.opendev.org/447983
Reason: This review is > 4 weeks without comment, and failed Jenkins the last time it was checked. We are abandoning this for now. Feel free to reactivate the review by pressing the restore button and leaving a 'recheck' comment to get fresh test results.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers