On Tuesday, October 7, 2014, Adam Young <ayo...@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@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
