Sahara doesn't work with secured network / OpenStack components

[Bill Stokes]

[Version 0.3.rc4] The Savanana endpoint and python-savannaclient don't work properly in secured environments. The ability to pass along a certificate to validate the token for Keystone, Nova, Cinder is not available, and causes these API calls to fail as unauthorized.

The Savanna REST API and CLI needs to provide a parameter for the OS CACERT (OPENSTACK_SSL_CACERT) and another to allow for insecure. These values would then be forwarded on to the corresponding OpenStack components (savanna/openstackl/utils/ files).

All keystone auth middleware configs should be exposed to the savanna.conf

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/66027

[Sergey Lukjanov (slukjanov)]

Sergey, why it's incomplete?

[Sergey Lukjanov (slukjanov)]

All configs of auth_token middleware should be exposed.

[Thierry Carrez (ttx)]

not covered by OpenStack VMT yet (no stable release yet)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/74688
Committed: https://git.openstack.org/cgit/openstack/sahara/commit/?id=1c70740f7d3f3da27998f8cde58180c127d18f74
Submitter: Jenkins
Branch: master

commit 1c70740f7d3f3da27998f8cde58180c127d18f74
Author: Sergey Lukjanov <email address hidden>
Date: Wed Feb 19 16:27:43 2014 +0400

    Rework keystone auth_token middleware configs

    We're using Sahara-specific configs and there are some other potential
    inconsistencies.

    * use common OpenStack [keystone_authtoken] section for middleware
      configurations;
    * token validator reworked to be consistent with update auth_token
      middleware usage;
    * auth_uri is now stored in context for consistency, additonally, it
    * provides correct auth_uri in multi process sahara deployment.

    Closes-Bug: #1257472
    Closes-Bug: #1249063

    Change-Id: I5a33ae6269d40dadcd4893b27a937a37e0c74006

[Tom Fifield (fifieldt)]

Was this ever fixed in python-saharaclient?

[Andrew Lazarev (alazarev)]

Resolved by https://review.openstack.org/#/c/145382/