[openstack-dev] [Neutron][python-neutronclient] Adding new options to the existing Neutron CLIs
amotoki at gmail.com
Sat Apr 2 13:18:50 UTC 2016
2016-03-18 12:06 GMT+09:00 reedip banerjee <reedip14 at gmail.com>:
> Dear All Neutron Developers and Reviewers,
> I have a query/concern related to the parsing of options in
> 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.
> 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
> . So therefore , if a user executes the following CLI
> " neutron net-create TestNetwork --router-external"
> then  would be observed as an output.
We can use "--router:external" since the initial support of neutron
You are talking about the situation that it is not described in the
It is better to have it in the help message.
> 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  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?
As Richard said, we don't plan to support the extra arguments in
so this is not a problem in the openstackclient migration.
In OpenStack Client, we should follow OpenStack client option convention.
I don't think it is a DEPRECATION of some options. It is a DERECATION
of neutronclient CLI itself.
> -- Should we deprecate them in NeutronClient itself, so that the users are
> comfortable with the options when the migration to Openstack Client occurs?
My vote is to keep the current behavior.
On the other hand I don't think we need to show all available patterns.
> -- Any other suggestions....
> : http://paste.openstack.org/show/491032/
> : 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
More information about the OpenStack-dev