Open Stack

Hi reedip,

On 2016/03/18 12:06, reedip banerjee wrote:
> 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?
>

IMO, we shouldn't support various methods to manage resources because I 
don't believe community keep maintaining all of them forever. It will 
collapse someday. We will have periods(two cycle?) for deprecation and 
then we should remove them from NeutronClient itself.

Thanks,
Hirofumi

> -- 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/929f00d6/attachment.html>