quantum port-create --fixed-ip ignores additional invalid items

[Gavin B]

When doing a port-create - and possibly other requests - you can add any old rubbish to the request, and provided the minimum required info is present, there is no error :

ubuntu@az3devstackvm2:~/devstack$ quantum port-create --fixed-ip subnet_id=1972dfa7-5537-465b-b41d-d3fdcd1de7ce,RUBBISH=SOMETHING 20147087-5520-4bb0-81a1-43ccbf2d101a
Created a new port:
+----------------+---------------------------------------------------------------------------------+
| Field | Value |
+----------------+---------------------------------------------------------------------------------+
| admin_state_up | True |
| device_id | |
| device_owner | |
| fixed_ips | {"subnet_id": "1972dfa7-5537-465b-b41d-d3fdcd1de7ce", "ip_address": "10.0.0.6"} |
| id | 78b68e9f-b414-40c8-af9e-0c537e5e45c8 |
| mac_address | fa:16:3e:a0:b6:82 |
| name | |
| network_id | 20147087-5520-4bb0-81a1-43ccbf2d101a |
| status | ACTIVE |
| tenant_id | 5e0d8b02dd0a448da10749dd5d33b88c |
+----------------+---------------------------------------------------------------------------------+
ubuntu@az3devstackvm2:~/devstack$

I have validated that the RUBBISH:SOMETHING is passed to the server, and is silently ignored.

This means that e.g. typos in commands can generate something other than the user was expecting :

ubuntu@az3devstackvm2:~/devstack$ q port-create --fixed-ip subnet_id=1972dfa7-5537-465b-b41d-d3fdcd1de7ce,ip-address=10.0.0.6 20147087-5520-4bb0-81a1-43ccbf2d101a
Created a new port:
+----------------+---------------------------------------------------------------------------------+
| Field | Value |
+----------------+---------------------------------------------------------------------------------+
| admin_state_up | True |
| device_id | |
| device_owner | |
| fixed_ips | {"subnet_id": "1972dfa7-5537-465b-b41d-d3fdcd1de7ce", "ip_address": "10.0.0.5"} |
| id | 008336f8-6fbd-4821-ab67-f9c8f70d0ab2 |
| mac_address | fa:16:3e:c6:ca:05 |
| name | |
| network_id | 20147087-5520-4bb0-81a1-43ccbf2d101a |
| status | ACTIVE |
| tenant_id | 5e0d8b02dd0a448da10749dd5d33b88c |
+----------------+---------------------------------------------------------------------------------+

I thought I was asking for 10.0.0.6, but I got 10.0.0.5

Would a 400 error not be more appropriate here ?

[Attila Fazekas (afazekas)]

Probably you are correct about this, but you should move this bug to the quantum projects side.

[Mathieu Rohon (mathieu-rohon)]

this could be a duplicate of this :
https://bugs.launchpad.net/quantum/+bug/1111572/comments/5

[Mark McClain (markmcclain)]

A recent fix to the Quantum server now results in a 400 error when extra fields are passed via the API. Part of the update to Quantum client library included between input validation before the request is submitted to the server. I'm moving the bug to the client project.

[dan wendlandt (danwent)]

Yeah, i need to think about this more. The new server change only checks
top-level keys, right? Perhaps we also need to improve api validation for
values that themeslves are dictionaries (and may have extra values).

[Akihiro Motoki (amotoki)]

This bug still exists.

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/253878
Committed: https://git.openstack.org/cgit/openstack/python-neutronclient/commit/?id=ed17ae60bd5fbcfffb94e91f270191f0b4d92970
Submitter: Jenkins
Branch: master

commit ed17ae60bd5fbcfffb94e91f270191f0b4d92970
Author: Akihiro Motoki <email address hidden>
Date: Sun Dec 6 16:55:24 2015 +0900

    Improve str2dict key validation to avoid wrong keys

    This commit adds valid_keys and required_keys to str2dict
    and define a new function which can be used as argparse type
    validator.

    By this function, we can declare what fields are valid and what
    fields are required for dictionary option in option definition.

    Change-Id: Ib7b233e082c15d0bd6e16a754b8acad52e413986
    Closes-Bug: #1102897

[Doug Hellmann (doug-hellmann)]

This issue was fixed in the openstack/python-neutronclient 4.1.0 release.