Subnet update with conflict gateway and allocation_pools succeed.

Bug #1062061 reported by Itsuro Oda
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
neutron
Fix Released
Medium
Mathieu Rohon

Bug Description

I think 409 is expected. Is this expected behavior ?

$ quantum subnet-create --name sub1 --no-gateway net-test 10.10.0.0/24
Created a new subnet:
+------------------+----------------------------------------------+
| Field | Value |
+------------------+----------------------------------------------+
| allocation_pools | {"start": "10.10.0.1", "end": "10.10.0.254"} |
| cidr | 10.10.0.0/24 |
| dns_nameservers | |
| enable_dhcp | True |
| gateway_ip | |
| host_routes | |
| id | 9c6ed6cf-2f2a-4146-b942-1d9a942c5194 |
| ip_version | 4 |
| name | sub1 |
| network_id | ff359fe5-7796-4314-8d4f-5457bd9e24ae |
| tenant_id | be3fc4694da2413c833574d6e018d338 |
+------------------+----------------------------------------------+
$ quantum subnet-update sub1 --gateway_ip 10.10.0.10
Updated subnet: sub1
$ quantum subnet-show sub1
+------------------+----------------------------------------------+
| Field | Value |
+------------------+----------------------------------------------+
| allocation_pools | {"start": "10.10.0.1", "end": "10.10.0.254"} |
| cidr | 10.10.0.0/24 |
| dns_nameservers | |
| enable_dhcp | True |
| gateway_ip | 10.10.0.10 |
| host_routes | |
| id | 9c6ed6cf-2f2a-4146-b942-1d9a942c5194 |
| ip_version | 4 |
| name | sub1 |
| network_id | ff359fe5-7796-4314-8d4f-5457bd9e24ae |
| tenant_id | be3fc4694da2413c833574d6e018d338 |
+------------------+----------------------------------------------+

Revision history for this message
Itsuro Oda (oda-g) wrote :

The first character of the title missing.

Subnet update with conflict gateway and allocation_pools succeed.

Akihiro Motoki (amotoki)
summary: - ubnet update with conflict gateway and allocation_pools succeed.
+ Subnet update with conflict gateway and allocation_pools succeed.
Revision history for this message
Akihiro Motoki (amotoki) wrote :

It is a reasonable solution that returning 409 for the above case.

Even if subnet-update returns 409 when a new gateway_ip overlaps with allocation_pool, we can update gateway_ip by doing the following sequence: first update allocation_pool to exclude a new gateway_ip and then update gateway_ip to the new value.

Revision history for this message
dan wendlandt (danwent) wrote :

I'd probably prefer the 409 approach, especially since it could be the case that the requested gateway_ip is already allocated out of the pool.

Changed in quantum:
status: New → Confirmed
importance: Undecided → Medium
Alex Xu (xuhj)
Changed in quantum:
assignee: nobody → He Jie Xu (xuhj)
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to quantum (master)

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

Changed in quantum:
status: Confirmed → In Progress
Revision history for this message
Gary Kotton (garyk) wrote :

When reviewing the fix I wrote "I am asking myself why the creation is treated differently from the update. That is, in the creation the gateway can be part of the allocation pool. I feel that the update should be the same. I do not see any reason why the gateway should not be allowed to be part of the allocation pool. If the IP address is used then we should fail, if not then the it should succeed and the allocation range updated accordingly.".
Any comments?

Revision history for this message
yong sheng gong (gongysh) wrote :
Download full text (3.3 KiB)

The current concept is when creating a subnet, the gateway_ip is excluded into the allocation_pools. So the allocation pools are for IPs that can be allocated to a given port.

I think we will have to remove this concept. I suggest to do it like this:
we can add gateway_ip as a part of the allocation pool, but we pre-allocate it. nova-network has the flags to mark some ips are reserved.

benefits are:
1.With gateway ips are treated as other normal ips, it will help with multihost too. in multihost feature, we will allocate one gateway ip for each host. With current allocation pools, we will not be able to do it.
2.We can deal with update well

Concerns:
1. should we change gateway ips of a subnet? what if we have created Vms on this subnets? These VMs will use the old gateways ips if they don't resync the network information.
2. this new conecpt need gateway ips must be on the cidr of the allocation pool. Can we have subnet 10.0.1.0/24 with gateway 8.0.2.1/32.
 quantum subnet-create pubnet2 10.0.1.0/24 --gateway_ip 8.0.2.1

Following are current concept illustrated by commands:
gongysh@gongysh-laptop:~/git/quantum$ quantum subnet-show 2de2ca4a-425c-4f69-b242-ec748125de71
+------------------+--------------------------------------------+
| Field | Value |
+------------------+--------------------------------------------+t
| allocation_pools | {"start": "10.0.2.2", "end": "10.0.2.254"} |
| cidr | 10.0.2.0/24 |
| dns_nameservers | |
| enable_dhcp | True |
| gateway_ip | 10.0.2.1 |
| host_routes | |
| id | 2de2ca4a-425c-4f69-b242-ec748125de71 |
| ip_version | 4 |
| name | |
| network_id | 6decf027-1a88-4641-9293-9fb935162f06 |
| tenant_id | b7445f221cda4f4a8ac7db6b218b1339 |
+------------------+--------------------------------------------+
gongysh@gongysh-laptop:~/git/quantum$ quantum subnet-create pubnet2 8.8.8.0/24 --gateway_ip 8.8.8.20
Created a new subnet:
+------------------+-------------------------------------------+
| Field | Value |
+------------------+-------------------------------------------+
| allocation_pools | {"start": "8.8.8.1", "end": "8.8.8.19"} |
| | {"start": "8.8.8.21", "end": "8.8.8.254"} |
| cidr | 8.8.8.0/24 |
| dns_nameservers | |
| enable_dhcp | True |
| gateway_ip | 8.8.8.20 |
| host_routes | |
| id | 4d9cd0c1-7c07-40bb-be4c-9ef7dc3a26d6 |
| ip_version | 4 |
| name | |
| network_id | 6decf027-1a88-4641-9293-9fb...

Read more...

Revision history for this message
Gary Kotton (garyk) wrote :

Hi,
Yes, I agree one option is to add the gateway ip address to the initial allocation pool. This will enable us to recycle this IP address if the user decides to update the gateway to another address.
An upgrade from folsom will need to be treated. The database schema has not changed by the database values may need to be changed.
Thanks
Gary

Alex Xu (xuhj)
Changed in quantum:
assignee: Alex Xu (xuhj) → nobody
Alex Xu (xuhj)
Changed in quantum:
status: In Progress → Confirmed
Changed in quantum:
assignee: nobody → mat (mathieu-rohon)
Revision history for this message
Gary Kotton (garyk) wrote :

Hi,
Please see https://bugs.launchpad.net/quantum/+bug/1096532. This may address part of this problem.
Thanks
Gary

tags: added: api
Revision history for this message
Mathieu Rohon (mathieu-rohon) wrote :

HI,
thanks gary for the link and for your work.
I have also reported another bug which is also related to the subnet-update :

https://bugs.launchpad.net/quantum/+bug/1111572

Revision history for this message
Mathieu Rohon (mathieu-rohon) wrote :

hi,

when a subnet is created, with both --allocation-pool and --gateway, we still have the 409 response :
# quantum subnet-create --name subnet1 --gateway 10.0.18.5 --allocation-pool start=10.0.18.2,end=10.0.18.10 net1 10.0.18.0/24
Found overlapping allocation pools:{u'start': u'10.0.18.2', u'end': u'10.0.18.10'} 10.0.18.5 for subnet 10.0.18.0/24.
# quantum subnet-create --name subnet1 --gateway 10.0.18.5 --allocation-pool start=10.0.18.6,end=10.0.18.10 net1 10.0.18.0/24
Created a new subnet:
+------------------+---------------------------------------------+
| Field | Value |
+------------------+---------------------------------------------+
| allocation_pools | {"start": "10.0.18.6", "end": "10.0.18.10"} |
| cidr | 10.0.18.0/24 |
| dns_nameservers | |
| enable_dhcp | True |
| gateway_ip | 10.0.18.5 |
| host_routes | |
| id | 45f6cda9-3746-4a13-b918-0e033331fa47 |
| ip_version | 4 |
| name | subnet1 |
| network_id | 68e6b68d-d4c6-4247-9466-0f3cd58b7258 |
| tenant_id | 57ffb85101824a73ae4872ab0c6780cf |
+------------------+---------------------------------------------+

do you feel like in this case, like when creating without a --allocation-pool, the requested pool should be devided in two subnet?

Concerning the subnet-update, putting a gateway in the allocation-pool requires to update the pool which is read-only.
The gongysh proposal, to allow the gateway in the allocation-pool is much tricky, especially if we want a backport to folsom.

Revision history for this message
Mathieu Rohon (mathieu-rohon) wrote :

to summarize this complicated bug and as discuss gary and gongysh on irc, the 409 reply while trying to update the gateway in the dhcp-pool seems to be the simplest solution with a possible backport to folsom. it should be backward compatible and It will be in line with the subnet-create bahavior when it is called with a gateway in the specified pool.

the fact that gateways could be owned by the allocation-pool, as a reserved ip, to help the multihost mode, should be handle in a new BP

Revision history for this message
Salvatore Orlando (salvatore-orlando) wrote :

Hi maroh,

Are you willing to fix this for Grizzly-3? I can target the bug in this case.

tags: added: folsom-backport-potential
Revision history for this message
Mathieu Rohon (mathieu-rohon) wrote :

hi salvatore,

i''ll post a new review, rebasing the code of alex xu. It's OK for G3

Revision history for this message
OpenStack Infra (hudson-openstack) wrote :

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

Changed in quantum:
status: Confirmed → In Progress
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to quantum (master)

Reviewed: https://review.openstack.org/21432
Committed: http://github.com/openstack/quantum/commit/41b6ac4b1b02ce5390f0eac72771f3333a0c5dff
Submitter: Jenkins
Branch: master

commit 41b6ac4b1b02ce5390f0eac72771f3333a0c5dff
Author: mathieu-rohon <email address hidden>
Date: Thu Feb 7 16:05:22 2013 +0100

    Add check for subnet update with conflict gateway and allocation_pools

    Fixes: bug 1062061

    The patch will raise exception 'GatewayConflictWithAllocationPools' when
    subnet update with conflict gateway and allocation_pools.

    Because before validate gateway ip with conflict allocation pools, we need
    validate allocation pools first. Move the validation of allocation pools
    into _validate_subnet. Then_allocate_pools_for_subnet is only responsible
    for pools allocation, and_validate_subnet is responsible for most validate
    for subnet.

    Change-Id: I8dffe45ce5c02e8e6c317bad470054564538bcf2

Changed in quantum:
status: In Progress → Fix Committed
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to quantum (stable/folsom)

Fix proposed to branch: stable/folsom
Review: https://review.openstack.org/21890

Akihiro Motoki (amotoki)
Changed in quantum:
milestone: none → grizzly-3
Thierry Carrez (ttx)
Changed in quantum:
status: Fix Committed → Fix Released
Thierry Carrez (ttx)
Changed in quantum:
milestone: grizzly-3 → 2013.1
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.