----- Original Message -----
> From: "Dean Troyer" <dtro...@gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev@lists.openstack.org>
> Sent: Tuesday, February 4, 2014 9:31:57 AM
> Subject: Re: [openstack-dev] Ugly Hack to deal with multiple versions
>
> On Mon, Feb 3, 2014 at 1:50 PM, Adam Young < ayo...@redhat.com > wrote:
>
> HACK: In a new client, look at the URL. If it ends with /v2.0, chop it off
> and us the substring up to that point.
>
> Now, at this point you are probably going: That is ugly, is it really
> necessary? Can't we do something more correct?
>
> At this point I think we are stuck with hard-coding some legacy compatibility
> like this for the near future. Fortunately Identity is an easy one to
> handle, Compute is going to be a #$^%! as the commonly documented case has a
> version not at the end.
>
> I've been playing with variations on this strategy and I think it is our
> least bad option...
>
>
>
> Can we accept that this is necessary, and vow to never let this happen again
> by removing the versions from the URLs after the current set of clients are
> deprecated?
> +1
>
> There is another hack to think about: if public_endpoint and/or
> admin_endpoint are not set in keystone.conf, all of the discovered urls use
> localhost: http://localhost:8770/v2.0/ . Discovery falls over aga
>
> I don't know how common this is but I have encountered it at least once or
> twice. Is this the only place those config values are used? It seems like a
> better default could be worked out here too; is 'localhost' ever the right
> thing to advertise in a real-world deployment?
I've not come across that one so much as something similar i've been wanting to
raise. Version discovery happens across either a public or an internal URL
and we retrieve the version list which has links to version endpoints.
These links in discovery are fully qualified and so it doesn't matter if you
connect to the server across the internal or public address you will always end
up communicating with the links specified in the config's public_endpoint
value.
I propose for this situation we allow (and make default asap) that links in
discovery can be relative links in the standard <a href="" /> manner (ie
python's urljoin rather than the just append it that we do now) joined onto
the URL that took us to the page.
So keystone:
{'versions': {'values': [{'id': 'v3.0',
'links': [{'href': '/v3/',
'rel': 'self'}],
'status': 'stable',
'updated': '2013-03-06T00:00:00Z'},
{'id': 'v2.0',
'links': [{'href': '/v2.0/',
'rel': 'self'},
'status': 'stable',
'updated': '2013-03-06T00:00:00Z'}]}}
> dt
>
> --
>
> Dean Troyer
> dtro...@gmail.com
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
