<br><br>On Tuesday, October 7, 2014, Adam Young <<a href="mailto:ayoung@redhat.com">ayoung@redhat.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
<br>
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.</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote><div><br></div><div>The response is cacheable.<span></span></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Is this significant?<br>
<br>
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.<br>
<br>
<br>
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.<br>
<br>
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.<br>
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a>OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</blockquote>