Open Stack

OpenStackClient (OSC) doesn't and won't allow "unsupported" CLI options. 
With the transition to OSC, the plan is to deprecate the neutron client 
CLI which will implicitly include the deprecation of such options.

Richard Theis (rtheis)
rtheis at us.ibm.com



From:   reedip banerjee <reedip14 at gmail.com>
To:     openstack-dev at lists.openstack.org
Date:   03/17/2016 10:09 PM
Subject:        [openstack-dev] [Neutron][python-neutronclient] Adding new 
options to the existing Neutron CLIs



Dear All Neutron Developers and Reviewers,

I have a query/concern related to the parsing of options in 
python-neutronclient.
I would like to bring this up, as it "may" also impact the transition of 
the CLIs to the openstack client as well.

NeutronClient is pretty special in its behavior, and has one pretty 
powerful feature of parsing extra options. This feature states that, if 
the CLI does not support an option but the API does, and the user passes a 
value for this option, then the "unsupported" CLI option is parsed , and 
forwarded to the Neutron Server for processing.

Example:
Currently "neutron net-create" does not support --router:external. If you 
see the output of "neutron net-create -h" you would not find 
"--router-external". However, this option is supported in the API since 
Juno [2]. So therefore , if a user executes the following CLI 
" neutron net-create TestNetwork --router-external" 

then [1] would be observed as an output.

Now the query/concern comes next....
Any option which is not supported by the CLI is open to the above parsing.
Therefore , for net-create and net-update, all the following are possible:

neutron net-create --router:external=True TESTNetwork --(A)
neutron net-create --router:external TESTNetwork  --(B)
neutron net-create TESTNetwork --router:external --(C)
neutron net-create TESTNetwork --router:external=True --(D)
neutron net-create TESTNetwork --router:external True --(E)
However, user is not aware of the --router:external option because it is 
not visible in the HELP section ( this is true for other CLI options as 
well).
In order to demonstrate these options to the User, we have to update 
add_known_arguments function to display them. And once they are known to 
the CLI, the parsing changes, and some of the options from (A) to (E) may 
not be supported ( Please see [3] for an ongoing, though now dormant, 
discussion ). 
Note that this discussion is not limited only to net-create, but possibly 
other CLIs as well which do not completely expose the Options which the 
API can support.I am , however, taking the net-create example as a 
case-study.
I would like to know how we can move forward in this regards:
-- Should NeutronClient continue to support all options from (A) to (E), 
but deprecate some of them in Openstack Client?
-- Should we deprecate them in NeutronClient itself, so that the users are 
comfortable with the options when the migration to Openstack Client 
occurs?
-- Any other suggestions....
[1]: http://paste.openstack.org/show/491032/
[2]: 
http://docs.openstack.org/juno/install-guide/install/apt/content/neutron_initial-external-network.html
[3]: https://review.openstack.org/#/c/137279/

-- 
Thanks and Regards,
Reedip Banerjee
IRC: reedip



__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160318/1fc0cf2a/attachment.html>