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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
