Open Stack

On Tuesday, October 7, 2014, Adam Young <ayoung at redhat.com> wrote:

> Horizon has a config options which says which version of the Keystone API
> it should work against:  V2 or V3.  I am not certain that there is still
> any reason for Horizon to go against V2. However, If we defer the decision
> to Keystone, we come up against the problem of discovery.
>
> On the surface it is easy, as the Keystone client supports  version
> discovery.  The problem is that discovery must be run for each new client
> creation, and Horizon uses a new client per request.  That would mean that
> every request to Horizon that talks to Keystone would generate at least one
> additional request.


The response is cacheable.


> Is this significant?
>
> It gets a little worse when you start thinking about all of the other
> services out there.  If each new request that has to talk to multiple
> services needs to run discovery, you can image that soon the majority of
> network chatter would be discovery based.
>
>
> It seems to me that Horizon should somehow cache this data, and share it
> among clients.  Note that I am not talking about user specific data like
> the endpoints from the service catalog for a specific project.  But the
> overall service catalog, as well as the supported versions of the API,
> should be cacheable.  We can use the standard HTTP cache management API on
> the Keystone side to specify how long Horizon can trust the data to be
> current.
>
> I think this actually goes for the rest of the endpoints as well: we want
> to get to  a much smaller service catalog, and we can do that by making the
> catalog holds on IDs.  The constraints spec for endpoint binding will be
> endpoint only anyway, and so having the rest of the endpoint data cached
> will be valuable there as well.
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141007/6193d57c/attachment.html>