Nova endpoint for v2.1 not parsed correctly, tries http instead of https

[Mike Lowe]

When the nova endpoint path is /v2.1 nova client always tries http but when the path is /v2.1/ it will try https when present in the url. OSC works correctly. Best guess is that endswith /v2.1 doesn't match but /v2.1/ in url.path does match. https://github.com/openstack/python-novaclient/blob/master/novaclient/v2/versions.py#L91 Problem exists with nova cli 9.1.0 and 10.2.0

[Matt Riedemann (mriedem)]

The problem is likely here:

https://github.com/openstack/python-novaclient/blob/10.3.0/novaclient/v2/versions.py#L91

See https://github.com/openstack/python-novaclient/commit/bd0a2adefe5e89c4269f6589837f871764c6f1f6 for reference.

I'm assuming there might be something in keystoneauth1 that can help parse the endpoint URL properly for us so we don't need this code in novaclient, but would need some help from the sdk team.

[Takashi Natsume (natsume-takashi)]

A similar problem was discussed in the openstack mailing list.

http://lists.openstack.org/pipermail/openstack/2018-July/046693.html

Can it (setting config in nova.conf) solve the issue in this report?

[melanie witt (melwitt)]

Takashi, thanks for linking that thread. To add the detail into this bug:

From that thread, the issue is that the /v2.1 URL triggers a redirect and nova-api redirects to an absolute URL. The /v2.1/ URL works because no redirect occurs. Bogdan Katynski explains:

"Looks to me that nova-api does a redirect to an absolute URL. I suspect SSL is terminated on the HAProxy and nova-api itself is configured without SSL so it redirects to an http URL.

In my opinion, nova would be more load-balancer friendly if it used a relative URI in the redirect but that’s outside of the scope of this question and since I don’t know the context behind choosing the absolute URL, I could be wrong on that.

I had a similar problem with heat-api running behind an Apache reverse proxy, and managed to resolve it by applying the workaround from this bug report:

https://bugs.launchpad.net/python-heatclient/+bug/1420907

Setting

X-Forwarded-Proto: https

before forwarding the request to heat-api fixed the issue for me."

[melanie witt (melwitt)]

Looks like this is the code we have that does the redirect from /v2.1 => /v2.1/ [1]:

ROUTE_LIST = (
    # NOTE: This is a redirection from '' to '/'. The request to the '/v2.1'
    # or '/2.0' without the ending '/' will get a response with status code
    # '302' returned.
    ('', '/'),

I'll ask Alex if he can take a look at this and let us know if there's a way we can redirect to a relative URL. The routes docs [2] mention that variables like "{url}" can be used in redirect call arguments, so I wonder if we can leverage that somehow.

[1] https://github.com/openstack/nova/blob/187f80a/nova/api/openstack/compute/routes.py#L399-L402
[2] http://routes.readthedocs.io/en/latest/uni_redirect_rest.html#redirect-routes

[Ghanshyam Mann (ghanshyammann)]

we can support the relative path also, I am not sure exact rational behind to redirect the relative to absolute path which is from history (not when we switched to route) [1]. May be Alex or John remember.

[1] https://github.com/openstack/nova/blob/stable/ocata/nova/api/openstack/compute/versionsV21.py#L59

We can support both /v2.1 and /v2.1/ and map those to 'GET': [version_controller, 'show'].

like this? - https://review.openstack.org/#/c/580544/2

Supporting that in backward compatible way can be discussed further.

[Ghanshyam Mann (ghanshyammann)]

That(https://review.openstack.org/#/c/580544/2) is just try the version API redirect things only not all other.

[melanie witt (melwitt)]

Based on the above comments, I don't think this is a problem in python-novaclient, but rather is related to the nova server redirect.

Bug 1728732 sounds like the same root issue and has more detail in the report, so I'm going to make this bug as a duplicate of it.