Bug 1029871 - [RFE][neutron]: Add the ability to update the IP allocation pool range for a subnet
[RFE][neutron]: Add the ability to update the IP allocation pool range for a...
Status: CLOSED ERRATA
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-neutron (Show other bugs)
3.0
x86_64 Linux
medium Severity low
: beta
: 6.0 (Juno)
Assigned To: Jakub Libosvar
Toni Freger
https://blueprints.launchpad.net/neut...
upstream_milestone_none upstream_stat...
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-11-13 07:09 EST by Jaroslav Henner
Modified: 2016-04-26 17:15 EDT (History)
14 users (show)

See Also:
Fixed In Version: openstack-neutron-2014.2.1-5.el7ost
Doc Type: Enhancement
Doc Text:
This enhancement enables changes to a subnet's IP address allocation pool using the update command. Previously, administrators were unable to change the allocation pool range for a subnet. If shrinking the pool, consideration must be given to IP addresses that have already been allocated.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-02-09 09:59:57 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Launchpad 1111572 None None None Never
Red Hat Knowledge Base (Solution) 696433 None None None Never
OpenStack gerrit 62042 None None None Never

  None (edit)
Description Jaroslav Henner 2013-11-13 07:09:46 EST
Description of problem:
We needed to increase the pool of floating ips, but it is not possible:

[root@controller ~(keystone_admin)]$ quantum subnet-update a52b0d51-c0a8-4eb2-b734-7a6f79f440bc --allocation-pool start=10.x.y.128,end=10.x.y.248
Unrecognized attribute(s) 'allocation_pool'
[root@controller ~(keystone_admin)]$ quantum subnet-update a52b0d51-c0a8-4eb2-b734-7a6f79f440bc --allocation-pools start=10.x.y.128,end=10.x.y.248
Cannot update read-only attribute allocation_pools


Version-Release number of selected component (if applicable):
openstack-quantum-2013.1.4-3.el6ost.noarch
python-quantumclient-2.2.1-2.el6ost.noarch


How reproducible:
always

Steps to Reproduce:
1. Have a (external) network, with a subnet
2. try updating the range
3.

Actual results:
not possible

Expected results:
range updated

Additional info:
Comment 2 Terry Wilson 2013-11-14 12:58:18 EST
The allocation pool setting is specifically listed as create/read-only in the upstream API docs: https://wiki.openstack.org/wiki/Neutron/APIv2-specification#Subnet. So neutron is behaving as-specified in this case, so this is not a bug and certainly doesn't have a severity of "high".

There is a blueprint that has been opened for a while on this: https://blueprints.launchpad.net/neutron/+spec/make-allocation-pool-updatable but no progress has been made and no target milestone set, so obviously a target of 4.0 here is inappropriate.

jhenner: as this is a feature request, do you still want to keep this bug open?
Comment 3 Jaroslav Henner 2013-11-15 17:48:47 EST
The fact that it is readonly makes impossible to increase the range without deleting all the ports (floating ips) that has been associated. It is very inconvenient. If one runs out of the floating IPs, there is probably no way to enlarge the pool. That' why I think it is high severity.
Comment 4 Jaroslav Henner 2013-11-15 17:51:27 EST
I would call this a design-flaw removal request.
Comment 8 lpeer 2014-12-15 04:12:16 EST
The functionality is available in OSP 6
Comment 11 Toni Freger 2014-12-31 03:48:56 EST
Hi, 

Have several questions.

1)As I see within BluePrint explanation:
https://blueprints.launchpad.net/neutron/+spec/make-allocation-pool-updatable

"Then it will ensure that the new range doesn't exclude any IPs that are currently in use. It will fail if the new pool excludes IPs currently in use"

Actual behaviour is, when the subnet update is decreasing the number of IP's in the range, and FloatingIp is already in use, the update succeeds and the excluded FloatingIp continue to function.

From the customer point of view I am also thinking that in the current situation the update should have failed.

Could you please clarify the expected behaviour for me?
 
2)Is this just CLI new functionality or it should be also in Horizon?
Comment 12 Toni Freger 2014-12-31 03:56:29 EST
Hi, 

I've finished the test plan, review will be appreciated

https://tcms.engineering.redhat.com/case/447857/?from_plan=14180

Thanks,
Toni
Comment 13 Jakub Libosvar 2015-01-12 04:15:18 EST
(In reply to Toni Freger from comment #11)
> Hi, 
> 
> Have several questions.
> 
> 1)As I see within BluePrint explanation:
> https://blueprints.launchpad.net/neutron/+spec/make-allocation-pool-updatable
> 
> "Then it will ensure that the new range doesn't exclude any IPs that are
> currently in use. It will fail if the new pool excludes IPs currently in use"
> 
> Actual behaviour is, when the subnet update is decreasing the number of IP's
> in the range, and FloatingIp is already in use, the update succeeds and the
> excluded FloatingIp continue to function.
> 
> From the customer point of view I am also thinking that in the current
> situation the update should have failed.
> 
> Could you please clarify the expected behaviour for me?
I looked on implementation and it's not explicitly checking whether any fip is out of new subnet range. Specifically it validates only that start and end of allocation pool are valid, that new pool doesn't overlap with existing one and that new pool falls into subnet.

>  
> 2)Is this just CLI new functionality or it should be also in Horizon?
This is API functionality. I'm not sure how Horizon behaves here.
Comment 14 Toni Freger 2015-01-13 03:56:56 EST
I think that we need to inform user. 
Actually he will have active IPs that won't be part of the existing new pool.
Comment 15 Toni Freger 2015-01-13 05:22:44 EST
I've opened 2 U/S bugs

https://bugs.launchpad.net/neutron/+bug/1410171
https://bugs.launchpad.net/neutron/+bug/1410173

Thanks,
Toni
Comment 17 errata-xmlrpc 2015-02-09 09:59:57 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHEA-2015-0148.html

Note You need to log in before you can comment on or make changes to this bug.