[Openstack] [openstack-dev] [nova][api] Novaclient redirect endpoint https into http
On 07/05/2018 01:55 PM, melanie witt wrote:
> 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.',
>> 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 . 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:
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
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)