On Mon, Oct 14, 2013 at 7:20 PM, Jamie Lennox <jamielen...@redhat.com>wrote:
> On Mon, 2013-10-14 at 18:36 -0700, Bhuvan Arumugam wrote: > > Just making sure i'm not the only one facing this problem. > > https://bugs.launchpad.net/nova/+bug/1239894 > > Yep, we thought this may raise some issues but insecure by default was > just not acceptable. > I think we should document it. > > > keystoneclient v0.4.0 was released last week and used by all openstack > > services now. The insecure=False, as defined in > > keystoneclient.middleware.auth_token. The keystone client is happy as > > long as --insecure flag is used. There is no way to configure it in > > other openstack services like nova, neutron or glance while it is > > integrated with self-signed keystone instance. > > I'm not following the problem. As you mentioned before the equivalent > setting for --insecure in auth_token is setting insecure=True in the > service's config file along with all the other keystone auth_token > settings. The equivalent when using the client library is passing > insecure=True to the client initialization. > Yep, the problem is solved after setting this flag in [filter:authtoken] section in /etc/nova/api-paste.ini. > > We should introduce new config parameter keystone_api_insecure and > > configure keystoneclient behavior based on this parameter. The config > > parameter should be defined in all other openstack services, as all of > > them integrate with keystone. > > A new config parameter where? I guess we could make insecure in > auth_token also response to an OS_SSL_INSECURE but that pattern is not > followed for any other service or parameter. > I think we are inconsistent in using this flag for different services. For instance, we use: neutron_api_insecure glance_api_insecure for keystone, we use: insecure=True I think it's reasonable as one way or the other, it's configurable. We'll be good if we document it somwhere here. http://docs.openstack.org/developer/python-keystoneclient/using-api.html > Until it's resolved, I think the known workaround is to use > > keystoneclient==0.3.2. > > > > > > Is there any other workaround for this issue? > > Signed certificates. > Oh yeah! we use signed cert in our prod environment. This one is our test bed. Thank you, -- Regards, Bhuvan Arumugam www.livecipher.com
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
