Open Stack

I have an IceHouse OpenStack installation, where the endpoints are using 
https as protocol (i.e. in the keystone.endpoint table  the https 
protocol is specified).

Now, I want to migrate this installation to Kilo. For this purpose I 
followed these steps:

- I scratched the controller/network node, but the DB was untouched (it 
resides on different machines), and re-installed with CentOS7
- I installed the Juno rpms (without configuring Juno services)
- I synced the keystone DB to the Juno version using the usual "db_sync" 
command:

     su -s /bin/sh -c "keystone-manage db_sync" keystone

- Then, I scratched the controller/network node, re-installed again with 
CentOS7 and installed all the Kilo RPMs required to sync the DB to the 
Kilo version.
With all the Kilo's RPM installed, I started from there to configure the 
Kilo Keystone service as described in the official guide 
docs.openstack.org.

That installation configures Keystone exposing v3 API, which can be used 
only with the openstackclient (and not by the legacy keystone one). But 
it seems there's a problem with the https endpoints.

After setting the following env vars

export OS_PROJECT_DOMAIN_ID=default
export OS_USER_DOMAIN_ID=default
export OS_PROJECT_NAME=admin
export OS_TENANT_NAME=admin
export OS_USERNAME=admin
export OS_PASSWORD=XXXXXXXX
export OS_AUTH_URL=https://cloud-areapd-test.pd.infn.it:35357/v3
export OS_CACERT=/etc/grid-security/certificates/INFN-CA-2006.pem

openstack fires out the following error:

[root at controller-01 ~]# openstack user list
/usr/lib/python2.7/site-packages/requests/packages/urllib3/util/ssl_.py:90: 
InsecurePlatformWarning: A true SSLContext object is not available. This 
prevents urllib3 from configuring SSL appropriately and may cause 
certain SSL connections to fail. For more information, see 
https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning. 

   InsecurePlatformWarning
ERROR: openstack Unable to establish connection to 
http://cloud-areapd-test.pd.infn.it:35357/v3/auth/tokens


With a deeper investigation I see that the Keystone service returns an 
"http" protocol for the endpoint despite the fact that there's https in 
the backend database:

[root at controller-01 ~]# curl -g -i --cacert 
"/etc/grid-security/certificates/INFN-CA-2006.pem" -X GET 
https://cloud-areapd-test.pd.infn.it:35357/v3 -H "Accept: 
application/json" -H "User-Agent: python-keystoneclient"
HTTP/1.1 200 OK
Vary: X-Auth-Token
Content-Type: application/json
Content-Length: 268
X-Openstack-Request-Id: req-a47a2873-f81b-490a-b249-7f970754914b
Date: Tue, 27 Oct 2015 10:32:20 GMT
Connection: close

{"version": {"status": "stable", "updated": "2015-03-30T00:00:00Z", 
"media-types": [{"base": "application/json", "type": 
"application/vnd.openstack.identity-v3+json"}], "id": "v3.4", "links": 
[{"href": "http://cloud-areapd-test.pd.infn.it:35357/v3/", "rel": 
"self"}]}}

The above curl command is grabbed from the output of "openstack --debug 
user list".

If I switch back to v2.0 API in env var OS_AUTH_URL, keystone client 
works correctly (and openstack stops working) and shows me the users, 
tenants, etc.:

[root at controller-01 ~]# export 
OS_AUTH_URL=https://cloud-areapd-test.pd.infn.it:35357/v2.0
[root at controller-01 ~]# keystone user-list
/usr/lib/python2.7/site-packages/keystoneclient/shell.py:65: 
DeprecationWarning: The keystone CLI is deprecated in favor of 
python-openstackclient. For a Python library, continue using 
python-keystoneclient.
   'python-keystoneclient.', DeprecationWarning)
/usr/lib/python2.7/site-packages/requests/packages/urllib3/util/ssl_.py:90: 
InsecurePlatformWarning: A true SSLContext object is not available. This 
prevents urllib3 from configuring SSL appropriately and may cause 
certain SSL connections to fail. For more information, see 
https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning. 

   InsecurePlatformWarning
+----------------------------------+----------+---------+---------------------+ 

|                id                |   name   | enabled | email        |
+----------------------------------+----------+---------+---------------------+ 

| 62e64ee442cc42e7b07c0209010148c3 |  admin   |   True  | ADMIN_EMAIL     |
| 96ab92677d43476a820428e281d229f2 |  cinder  |   True  | 
cinder at example.co |
| e737d7af46ab46838bbef6c5d16aff7e |  glance  |   True  | 
glance at example.com |
| 84546c19c2b242738235022f73b2e9c2 | neutron  |   True  | 
neutron at example.com |
| b99c5365b6c448d4956fdae02fe0ef11 |   nova   |   True  | 
nova at example.com |
| 3c2bde47975b4f738b316d87f3727ec3 | sgaravat |   True 
|                     |
+----------------------------------+----------+---------+---------------------+ 



So, the question is: is there a bug in the service code which forcely 
translates https to http ?

thanks,

     Alvise Dorigo