<br><br>On Monday, October 14, 2013, Jamie Lennox  wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, 2013-10-14 at 18:36 -0700, Bhuvan Arumugam wrote:<br>

> Just making sure i'm not the only one facing this problem.<br>
> <a href="https://bugs.launchpad.net/nova/+bug/1239894" target="_blank">https://bugs.launchpad.net/nova/+bug/1239894</a><br>
<br>
Yep, we thought this may raise some issues but insecure by default was<br>
just not acceptable.<br>
<br>
> keystoneclient v0.4.0 was released last week and used by all openstack<br>
> services now. The insecure=False, as defined in<br>
> keystoneclient.middleware.auth_token. The keystone client is happy as<br>
> long as --insecure flag is used. There is no way to configure it in<br>
> other openstack services like nova, neutron or glance while it is<br>
> integrated with self-signed keystone instance.<br>
<br>
I'm not following the problem. As you mentioned before the equivalent<br>
setting for --insecure in auth_token is setting insecure=True in the<br>
service's config file along with all the other keystone auth_token<br>
settings. The equivalent when using the client library is passing<br>
insecure=True to the client initialization.<br>
<br>
> We should introduce new config parameter keystone_api_insecure and<br>
> configure keystoneclient behavior based on this parameter. The config<br>
> parameter should be defined in all other openstack services, as all of<br>
> them integrate with keystone.<br>
<br>
A new config parameter where? I guess we could make insecure in<br>
auth_token also response to an OS_SSL_INSECURE but that pattern is not<br>
followed for any other service or parameter.<br>
<br></blockquote><div><br></div><div> That's something I'd rather not support without a *very* strong use case. Using --insecure is inconvenient by design.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

> Until it's resolved, I think the known workaround is to use<br>
> keystoneclient==0.3.2.<br>
><br>
><br>
> Is there any other workaround for this issue?<br>
<br>
Signed certificates.<br>
<br>
> --<br>
> Regards,<br>
> Bhuvan Arumugam<br>
> <a href="http://www.livecipher.com" target="_blank">www.livecipher.com</a><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="javascript:;" onclick="_e(event, 'cvml', 'OpenStack-dev@lists.openstack.org')">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="javascript:;" onclick="_e(event, 'cvml', 'OpenStack-dev@lists.openstack.org')">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote><br><br>-- <br><div><br></div>-Dolph<br>