Open Stack

On 07/05/2018 01:55 PM, melanie witt wrote:
> +openstack-dev@
> 
> On Wed, 4 Jul 2018 14:50:26 +0000, Bogdan Katynski wrote:
>>> But, I can not use nova command, endpoint nova have been redirected 
>>> from https to http. Here:http://prntscr.com/k2e8s6  (command: nova 
>>> –insecure service list)
>> First of all, it seems that the nova client is hitting /v2.1 instead 
>> of /v2.1/ URI and this seems to be triggering the redirect.
>>
>> Since openstack CLI works, I presume it must be using the correct URL 
>> and hence it’s not getting redirected.
>>
>>> And this is error log: Unable to establish connection 
>>> tohttp://192.168.30.70:8774/v2.1/: ('Connection aborted.', 
>>> BadStatusLine("''",))
>> 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.
> 
> Thanks for mentioning this. We do have a bug open in python-novaclient 
> around a similar issue [1]. I've added comments based on this thread and 
> will consult with the API subteam to see if there's something we can do 
> about this in nova-api.

A similar thing came up the other day related to keystone and version 
discovery. Version discovery documents tend to return full urls - even 
though relative urls would make public/internal API endpoints work 
better. (also, sometimes people don't configure things properly and the 
version discovery url winds up being incorrect)

In shade/sdk - we actually construct a wholly-new discovery url based on 
the url used for the catalog and the url in the discovery document since 
we've learned that the version discovery urls are frequently broken.

This is problematic because SOMETIMES people have public urls deployed 
as a sub-url and internal urls deployed on a port - so you have:

Catalog:
public: https://example.com/compute
internal: https://compute.example.com:1234

Version discovery:
https://example.com/compute/v2.1

When we go to combine the catalog url and the versioned url, if the user 
is hitting internal, we product 
https://compute.example.com:1234/compute/v2.1 - because we have no way 
of systemically knowing that /compute should also be stripped.

VERY LONG WINDED WAY of saying 2 things:

a) Relative URLs would be *way* friendlier (and incidentally are 
supported by keystoneauth, openstacksdk and shade - and are written up 
as being a thing people *should* support in the documents about API 
consumption)

b) Can we get agreement that changing behavior to return or redirect to 
a relative URL would not be considered an api contract break? (it's 
possible the answer to this is 'no' - so it's a real question)

Monty