Fuelclient from remote host get token error

[Julia Portnova]

When I try to use fuelclient from remote host I get timeout error on getting token from keystone.
That is because keystone client is initialized with wrong url in keystoneclient.client.

Workaround is using keystoneclient.v2_0.client.

[Dima Shulyak (dshulyak)]

It is clearly because of interaction with nginx:

>> curl http://172.18.76.201:5000/v2.0 | jq '.'

{
  "version": {
    "links": [
      {
        "rel": "self",
        "href": "http://172.18.76.201:5000/v2.0/"
      },

>> curl http://172.18.76.201:8000/keystone/v2.0 | jq '.'
{
  "version": {
    "links": [
      {
        "rel": "self",
        "href": "http://10.108.80.2:5000/v2.0/"
      },

It works only if ipaddress of server is routable from your host, which should not be mandatory,
raising this to high, because we can easily provide workaround to turn off keystone discovery mechanism

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/143817
Committed: https://git.openstack.org/cgit/stackforge/fuel-library/commit/?id=34238f354ff5a462a5cd187b740ca946a3e78bcb
Submitter: Jenkins
Branch: master

commit 34238f354ff5a462a5cd187b740ca946a3e78bcb
Author: Igor Kalnitsky <email address hidden>
Date: Wed Dec 24 12:50:46 2014 +0200

    Set "Host" header when proxying to Keystone

    Nginx has to set correct "Host" header when proxying requests to Keystone,
    because Keystone uses it during self auto-discovering.

    Change-Id: I862c30b6b8021706284ebe1e197e3beabfc4294d
    Closes-Bug: #1405190

[Artem Panchenko (apanchenko-8)]

@Igor,

setting 'Host' header breaks port redirecting, keystone thinks that it get requests from 80/tcp port and returns incorrect links:

http://paste.openstack.org/show/154696/

That cause another issue: https://bugs.launchpad.net/fuel/+bug/1405686

If you need to keep original host address in proxied to keystone requests, let's put it directly in URL:

proxy_pass http://$host:5000/$1;

[Ihor Kalnytskyi (ikalnytskyi)]

@Artem,

Damn. I tested it with curl and on the moment of patch - all works fine.

As for proxy_pass - we can't use $host, since in theory our keystone service may be installed on another host. However, we can't keep things "As Is", because in that case our fuelcli doesn't work correctly.

[Ihor Kalnytskyi (ikalnytskyi)]

> Workaround is using keystoneclient.v2_0.client.

Looks like it's the only fix we can provide right now. Moreover, the similar way behaves our UI - just performs request on keystone, and don't rediscover its endpoint.

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/144146
Committed: https://git.openstack.org/cgit/stackforge/fuel-web/commit/?id=df4f1d9bcc6c9755fefb2654a13e817cf50ab7bd
Submitter: Jenkins
Branch: master

commit df4f1d9bcc6c9755fefb2654a13e817cf50ab7bd
Author: Igor Kalnitsky <email address hidden>
Date: Fri Dec 26 16:06:19 2014 +0200

    fuelclient: use keystone v2.0 client explicitly

    Currently, we're using a Keystone client which actually performs
    auto discovering and returns one of available client. In theory
    all works fine, but unfortunately the "auth_url" will be replaced
    by Keystone with a keystone endpoint. The issue is that this
    endpoint may be unavailable if we're working through some
    proxy/tunnel and don't have direct access to the fuel master node.

    As workaround, we can explicitly create a keystone client for v2.0,
    and none of discovering will be performed and the endpoint will not
    be replaced implicitly by keystone client.

    Change-Id: Ieada040739116227f53f70558cead5bcb4d5bb48
    Closes-Bug: #1405190

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/6.0
Review: https://review.openstack.org/156606

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/5.1
Review: https://review.openstack.org/156609

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/156606
Committed: https://git.openstack.org/cgit/stackforge/fuel-web/commit/?id=a27dcf6a04c12ab6c0bfa7039ffba84ed7574592
Submitter: Jenkins
Branch: stable/6.0

commit a27dcf6a04c12ab6c0bfa7039ffba84ed7574592
Author: Igor Kalnitsky <email address hidden>
Date: Fri Dec 26 16:06:19 2014 +0200

    fuelclient: use keystone v2.0 client explicitly

    Currently, we're using a Keystone client which actually performs
    auto discovering and returns one of available client. In theory
    all works fine, but unfortunately the "auth_url" will be replaced
    by Keystone with a keystone endpoint. The issue is that this
    endpoint may be unavailable if we're working through some
    proxy/tunnel and don't have direct access to the fuel master node.

    As workaround, we can explicitly create a keystone client for v2.0,
    and none of discovering will be performed and the endpoint will not
    be replaced implicitly by keystone client.

    Change-Id: Ieada040739116227f53f70558cead5bcb4d5bb48
    Closes-Bug: #1405190
    (cherry picked from commit df4f1d9bcc6c9755fefb2654a13e817cf50ab7bd)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/156609
Committed: https://git.openstack.org/cgit/stackforge/fuel-web/commit/?id=2245429119dc7cfdfb9c611e17df4e422fc6717a
Submitter: Jenkins
Branch: stable/5.1

commit 2245429119dc7cfdfb9c611e17df4e422fc6717a
Author: Alexandr Nevenchannyy <email address hidden>
Date: Tue Feb 17 17:59:47 2015 +0300

    fuelclient: use keystone v2.0 client explicitly

    Currently, we're using a Keystone client which actually performs
    auto discovering and returns one of available client. In theory
    all works fine, but unfortunately the "auth_url" will be replaced
    by Keystone with a keystone endpoint. The issue is that this
    endpoint may be unavailable if we're working through some
    proxy/tunnel and don't have direct access to the fuel master node.

    As workaround, we can explicitly create a keystone client for v2.0,
    and none of discovering will be performed and the endpoint will not
    be replaced implicitly by keystone client.

    Change-Id: Ieada040739116227f53f70558cead5bcb4d5bb48
    Closes-Bug: #1405190
    (cherry picked from commit df4f1d9bcc6c9755fefb2654a13e817cf50ab7bd)