[openstack-dev] [Openstack] [nova][api] Novaclient redirect endpoint https into http

Kristi Nikolla knikolla at bu.edu
Fri Jul 6 11:28:53 UTC 2018


On Thu, Jul 5, 2018 at 4:11 PM Monty Taylor <mordred at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



More information about the OpenStack-dev mailing list