On Thu, Jul 5, 2018 at 4:11 PM Monty Taylor <mord...@inaugust.com> wrote: > > 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)
If the answer is 'no', can we find a process that gets us there? Or are we doomed by the inability to version the version document? > > 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 __________________________________________________________________________ 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