Open Stack

I had written a fix for the particular --timeout issue here that prevents
the client from parsing options beyond the subcommand:
https://review.openstack.org/#/c/114005/

At the time I abandoned it since we figured it would be safer to just
rename our HTTP timeout option to --http-timeout, but maybe something like
that could be done for os-client-config?

On Tue, Jan 5, 2016 at 5:45 AM, Akihiro Motoki <amotoki at gmail.com> wrote:

> A series of os-client-config integration for neutronclient are proposed.
> Several questions hit me during reviewing
> https://review.openstack.org/#/c/242096.
> It is a review of neutroncleint, but I think it is generic to all CLIs.
>
>
> (1) global option vs command-specific option
>
> Various python-*client supports --timeout global option to specify HTTP
> timeout.
> In neutronclient, --timeout option is used by lb-healthmonitor-create and
> others
> and we use --http-timeout as a global option to specify HTTP timeout.
>
> The above review proposes to use os-client-config for common arguments.
> This itself is great, but it breaks the current options.
>
> My understanding is this is the limitation of argparse.
> Is there any suggested guidelines on how to manage global options?
>
>
> (2) --os-interface vs --os-endpoint-type
>
> Do we need to deprecate --os-endpoint-type in favar of --os-interface?
> openstack client and os-client-config use --os-interface.
> Most per-project CLI use --os-endpoint-type now.
> Is --os-interface our way to go?
>
>
> Thanks,
> Akihiro
>
> __________________________________________________________________________
> 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
>



-- 
Kevin Benton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160105/1cc854ab/attachment.html>