Open Stack

This may have landed relatively recently, but:

$ keystone help
[...]
Optional arguments:
  [...]
  --insecure            Explicitly allow keystoneclient to perform
"insecure"
                        SSL (https) requests. The server's certificate will
                        not be verified against any certificate authorities.
                        This option should be used with caution.


-Dolph


On Tue, Nov 27, 2012 at 10:14 AM, Brian Waldon <bcwaldon at gmail.com> wrote:

>
> On Nov 27, 2012, at 9:59 AM, Jay Pipes wrote:
>
> > jp833r at c2r1:~$ keystone endpoint-list
> > No handlers could be found for logger "keystoneclient.client"
> > Authorization Failed: Unable to communicate with identity service:
> > [Errno 1] _ssl.c:504: error:14090086:SSL
> > routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed. (HTTP
> 400)
> > jp833r at c2r1:~$ keystone --insecure endpoint-list
> > usage: keystone [--os_username <auth-user-name>]
> > <snip>
> >                <subcommand> ...
> > keystone: error: unrecognized arguments: --insecure
> >
> > Whereas nova has the --insecure option, but doesn't have such a nice
> > error message indicating that certificate verify failed :)
> >
> > jp833r at c2r1:~$ nova list
> > ERROR: n/a (HTTP 400)
> > jp833r at c2r1:~$ nova --insecure list
> > +----+------+--------+----------+
> > | ID | Name | Status | Networks |
> > +----+------+--------+----------+
> > +----+------+--------+----------+
> >
> > Thoughts? I think it would be great to get:
> >
> > 1) Some consistency between the two tools regarding how they indicate
> > that cert verification failed
>
> Yes, Dean Troyer has spent a lot of time and effort triaging the state of
> SSL support across the clients. I think he could offer some insight as to
> his plans there.
>
> > 2) An --insecure option consistent in all clients for use in
> > test/non-prod environments that have self-signed certs
>
> Yes, definitely agree. We need to standardize on several SSL-related
> options like --insecure.
>
> > 3) The ability for all CLI tools to support a --version option (or
> > version command)
>
> Yep, just added this to python-glanceclient (borrowed from
> python-novaclient). To be clear, this should represent the client library
> version, not the REST API version that the client is yelling at.

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