Comment 8 for bug 1111572

Actually quantum subnet-update will accept anything. Even allocation-poops. This is because it's been implemented in a way that it's extension friendly.

On the server side we have a long standing issue that it never complains if you send an unknown attribute. When you do
--allocation-pools I am not sure this is going to be translated into allocation_pools (dash replaced by underscore) in the api request which is sent. In that case, the server will just ignore 'allocation-pools'.

So the update is accepted, but it's actually not doing anything (indeed data are not updated).

For the quantum subnet-create operation instead I believe --allocation-pool is used in singular form because it can be repeated multiple times for distinct allocation pools. The issue here is that actually we should have the same sets of options for create and update operations.

Summarizing:
* I will triage for checking whether there are issues concerning specifically subnet_update operation on the API server. If not I will mark this bug as invalid
* I will file a quantum bug for forcing the server to return 400 for unknown attributes.
* I will file a python-quantumclient bug for allowing to specify the same options as create for update operations.

I think we need to do these improvements as this is not the first time this confusion occurs,