Open Stack

What's your output from keystone endpoint-list or keystone catalog (or the
DB table)? Is it possible the admin URL is simply listed as http?

On Tue, Oct 27, 2015 at 9:32 PM, Alvise Dorigo <alvise.dorigo at pd.infn.it>
wrote:

> 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
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20151028/c17ad789/attachment.html>