IPv6 two attributes cannot be updated to None

Bug #1362966 reported by Akihiro Motoki
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
OpenStack Dashboard (Horizon)
Invalid
Wishlist
Unassigned
neutron
Invalid
Medium
Ann Taraday

Bug Description

The default value of IPv6 RA and address modes is None (if they are not specified when the subnet is created).
However, we cannot change IPv6 two modes to None from other values after creating a subnet.
(ra_mode address_mode) = (None, None) is a valid combinaiton, but for example we cannot change them from (slaac, slaac) to (none, none).

IMO IPv6 two modes should accept None in API to allow users to reset the attribute value to None.

ubuntu@dev02:~/neutron (master)$ neutron subnet-show 4ab34962-b330-4be5-98fe-ac7862f8d511
+-------------------+---------------------------------------------------------------------------+
| Field | Value |
+-------------------+---------------------------------------------------------------------------+
| allocation_pools | {"start": "fe80:8888::2", "end": "fe80:8888:ff:ffff:ffff:ffff:ffff:fffe"} |
| cidr | fe80:8888::/40 |
| dns_nameservers | |
| enable_dhcp | True |
| gateway_ip | fe80:8888::1 |
| host_routes | |
| id | 4ab34962-b330-4be5-98fe-ac7862f8d511 |
| ip_version | 6 |
| ipv6_address_mode | slaac |
| ipv6_ra_mode | slaac |
| name | |
| network_id | 07315dce-0c6c-4c2f-99ec-e8575ffa72af |
| tenant_id | 36c29390faa8408cb9deff8762319740 |
+-------------------+---------------------------------------------------------------------------+

ubuntu@dev02:~/neutron (master)$ neutron subnet-update 4ab34962-b330-4be5-98fe-ac7862f8d511 --ipv6_ra_mode action=clear --ipv6_address_mode action=clear
Invalid input for ipv6_ra_mode. Reason: 'None' is not in ['dhcpv6-stateful', 'dhcpv6-stateless', 'slaac']. (HTTP 400) (Request-ID: req-9431df59-3881-4c85-861e-b25217b8013d)

Tags: api ipv6 neutron
Changed in neutron:
assignee: nobody → Eugene Nikanorov (enikanorov)
importance: Undecided → Medium
tags: added: api
Changed in neutron:
assignee: Eugene Nikanorov (enikanorov) → Ann Kamyshnikova (akamyshnikova)
Changed in neutron:
status: New → In Progress
Changed in python-neutronclient:
assignee: nobody → Sridhar Gaddam (sridhargaddam)
Revision history for this message
Sridhar Gaddam (sridhargaddam) wrote :

python-neutronclient is indeed making a call to Neutron Server with ipv6_ra_mode and ipv6_address_mode set to None and the error is seen on the Neutron Server. So, looks like we may not need any changes in neutronclient.

Error on Neutron Server (q-svc.log)
2014-10-03 16:08:27.121 ERROR neutron.api.v2.resource [req-a3a19ccf-cecc-410b-b7fb-05e34cec2d7a demo e90083df0cfe4efcaf33133601bf90c4] update failed
2014-10-03 16:08:27.121 TRACE neutron.api.v2.resource Traceback (most recent call last):
2014-10-03 16:08:27.121 TRACE neutron.api.v2.resource File "/opt/stack/neutron/neutron/api/v2/resource.py", line 87, in resource
2014-10-03 16:08:27.121 TRACE neutron.api.v2.resource result = method(request=request, **args)
2014-10-03 16:08:27.121 TRACE neutron.api.v2.resource File "/opt/stack/neutron/neutron/api/v2/base.py", line 501, in update
2014-10-03 16:08:27.121 TRACE neutron.api.v2.resource allow_bulk=self._allow_bulk)
2014-10-03 16:08:27.121 TRACE neutron.api.v2.resource File "/opt/stack/neutron/neutron/api/v2/base.py", line 640, in prepare_request_body
2014-10-03 16:08:27.121 TRACE neutron.api.v2.resource raise webob.exc.HTTPBadRequest(msg)
2014-10-03 16:08:27.121 TRACE neutron.api.v2.resource HTTPBadRequest: Invalid input for ipv6_ra_mode. Reason: 'None' is not in ['dhcpv6-stateful', 'dhcpv6-stateless', 'slaac'].
2014-10-03 16:08:27.121 TRACE neutron.api.v2.resource

Error reported in python-neutronclient:
Bad Request (HTTP 400) (Request-ID: req-a3a19ccf-cecc-410b-b7fb-05e34cec2d7a)

Once the problem is addressed in Neutron, we would not see the error on the client.

Changed in python-neutronclient:
assignee: Sridhar Gaddam (sridhargaddam) → nobody
Revision history for this message
Akihiro Motoki (amotoki) wrote :

There is no issues in python-neutronclient, so I remove neutronclient from the affected projects.

no longer affects: python-neutronclient
Revision history for this message
Akihiro Motoki (amotoki) wrote :

On Horizon side, update of IPv6 two modes is disabled until this bug is fixed in Neutron.
The logic is commented out in the initial Horizon implementation, so I mark this bug as Wishlist in Horizon.

tags: added: neutron
Changed in horizon:
importance: Undecided → Wishlist
Revision history for this message
Ann Taraday (akamyshnikova) wrote :

For some reason link to change was not added https://review.openstack.org/125328.

Revision history for this message
Akihiro Motoki (amotoki) wrote :

Sorry that I readded neutron client again.

subnet-update has --ipv6-ra-mode and --ipv6-address-mode option.
These options needs to support None.
This is the reason neutronclient is affected.

Changed in horizon:
assignee: nobody → Akihiro Motoki (amotoki)
Revision history for this message
Sean M. Collins (scollins) wrote :

This is not correct. Neutronclient should only set the ipv6_* attributes if a value is set. It shouldn't be setting an attribute when the value is None.

Revision history for this message
Sean M. Collins (scollins) wrote :

Ah. I see now, how do we handle deleting the attributes after they've been set. Tricky. Sometimes a value of None means "None" and sometimes it means "Delete the attribute"

Changed in neutron:
assignee: Ann Kamyshnikova (akamyshnikova) → Henry Gessau (gessau)
Revision history for this message
Akihiro Motoki (amotoki) wrote :

Yes, as Sean commented, there are some inconsistencies in Neutron API.
None has several meanings depending on the context :-(

* None is an actual value of an attribute (e.g., "gateway_ip" of subnet)
* Sending None in API clears the attribute (e.g., "session_persistence" in LBaaS VIP)
* Sending None in API has the same meaning of sending an empty list/dict

We need to have a consistent way when we discuss a new version of API,
but it is what we have now.

In IPv6 attribute case, there are several ways to handle this bug:
- to have more detail documentation on what operations are allowed (and not to change the current behavior)
- to disallow updating IPv6 modes completely
- to add a way to clear IPv6 modes (the proposed patch tries to do this)

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to neutron (master)

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

Akihiro Motoki (amotoki)
summary: - IPv6 two attributes cannot be set to None
+ IPv6 two attributes cannot be updated to None
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Change abandoned on neutron (master)

Change abandoned by Henry Gessau (<email address hidden>) on branch: master
Review: https://review.openstack.org/126781
Reason: As per IRC discussion we ran out of time to get this into Juno.

Akihiro Motoki (amotoki)
Changed in neutron:
assignee: Henry Gessau (gessau) → Ann Kamyshnikova (akamyshnikova)
Changed in neutron:
assignee: Ann Kamyshnikova (akamyshnikova) → Henry Gessau (gessau)
Changed in neutron:
assignee: Henry Gessau (gessau) → Ann Kamyshnikova (akamyshnikova)
Revision history for this message
OpenStack Infra (hudson-openstack) wrote :

Change abandoned by Henry Gessau (<email address hidden>) on branch: master
Review: https://review.openstack.org/125328
Reason: Updating of ipv6 mode attributes has been disabled.

Revision history for this message
Eugene Nikanorov (enikanorov) wrote :

Closing as Invalid as updating ipv6 address mode has been disabled in the neutron api

no longer affects: python-neutronclient
Changed in neutron:
status: In Progress → Invalid
Revision history for this message
Akihiro Motoki (amotoki) wrote :

Neutron won't support the update IPv6 modes, so there is nothing to do in horizon, so let's mark it as Invalid in horizon as well.

Changed in horizon:
assignee: Akihiro Motoki (amotoki) → nobody
status: New → Invalid
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.