Open Stack

----- Original Message -----
> From: "Dolph Mathews" <dolph.mathews at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
> 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 < jamielennox at redhat.com >
> wrote:
> 
> 
> 
> 
> ----- Original Message -----
> > From: "Dolph Mathews" < dolph.mathews at gmail.com >
> > To: "OpenStack Development Mailing List (not for usage questions)" <
> > openstack-dev at lists.openstack.org >
> > 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 < 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.
> 
> 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
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/ cgi-bin/mailman/listinfo/ openstack-dev
> > 
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>