----- Original Message ----- > From: "Dolph Mathews" <[email protected]> > To: "OpenStack Development Mailing List (not for usage questions)" > <[email protected]> > Sent: Monday, October 20, 2014 4:38:25 PM > Subject: Re: [openstack-dev] Horizon and Keystone: API Versions and Discovery > > > On Mon, Oct 20, 2014 at 7:04 AM, Jamie Lennox < [email protected] > > wrote: > > > > > ----- Original Message ----- > > From: "Dolph Mathews" < [email protected] > > > To: "OpenStack Development Mailing List (not for usage questions)" < > > [email protected] > > > Sent: Tuesday, October 7, 2014 6:56:15 PM > > Subject: Re: [openstack-dev] Horizon and Keystone: API Versions and > > Discovery > > > > > > > > On Tuesday, October 7, 2014, Adam Young < [email protected] > 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. > > Not only is it cachable it is cached by default within the Session object you > use so that the session will only make one discovery request per service per > session. So horizon can manage how long to cache discovery for by how long > they hold on to a session object. As the session object doesn't contain any > personal or sensitive date (that is all restricted to the auth plugin) the > session object can be persisted between requests. > > Is there any reason not to cache to disk across sessions? The GET response is > entirely endpoint-specific, not exactly session-based. >
The only reason is that I didn't want to introduce a global variable cache in a library. The session should be a fairly long running object and i'm looking at ways we could serialize it to allow horizon/CLIs to manage it themselves. A quicker way would be to make the discovery cache an actual object and allow horizon/CLIs to handle that seperately to the session/auth plugin. I don't know which they would prefer. > > Whether or not horizon works that way today - and whether the other services > work with discovery as well as keystone does i'm not sure. > > > > > 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 > > [email protected] > > http://lists.openstack.org/ cgi-bin/mailman/listinfo/ openstack-dev > > > > _______________________________________________ > > OpenStack-dev mailing list > > [email protected] > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
