Open Stack

On Mon, Oct 14, 2013 at 7:20 PM, Jamie Lennox <jamielennox at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131015/56a19af7/attachment.html>