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)
Reviewed: https:/ /review. openstack. org/156606 /git.openstack. org/cgit/ stackforge/ fuel-web/ commit/ ?id=a27dcf6a04c 12ab6c0bfa7039f fba84ed7574592
Committed: https:/
Submitter: Jenkins
Branch: stable/6.0
commit a27dcf6a04c12ab 6c0bfa7039ffba8 4ed7574592
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: Ieada0407391162 27f53f70558cead 5bcb4d5bb48 5fefb2654a13e81 7cf50ab7bd)
Closes-Bug: #1405190
(cherry picked from commit df4f1d9bcc6c975