Re: [openstack-dev] Horizon and Keystone: API Versions and Discovery
On Tue, Oct 21, 2014 at 8:34 AM, Jamie Lennox wrote: > 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. We need a generalized caching layer in all of the clients, a session/auth cache is just another instance of that. I've been working under the assumption for OSC that I'd be doing most of that work and that it would live in OSC initially. I like the idea of a cache object that the app subclasses and hands back to the Session, then anything using the Session can make the callbacks. dt -- Dean Troyer dtro...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Horizon and Keystone: API Versions and Discovery
- Original Message - > From: "Dolph Mathews" > To: "OpenStack Development Mailing List (not for usage questions)" > > 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 < jamielen...@redhat.com > > wrote: > > > > > - Original Message - > > From: "Dolph Mathews" < dolph.math...@gmail.com > > > To: "OpenStack Development Mailing List (not for usage questions)" < > > openstack-dev@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 < 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. > > 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@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 > > > > ___ > 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 > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Horizon and Keystone: API Versions and Discovery
On Mon, Oct 20, 2014 at 7:04 AM, Jamie Lennox wrote: > > > - Original Message - > > From: "Dolph Mathews" > > To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@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 < 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. > > 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. > > 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@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 > > > > ___ > 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
Re: [openstack-dev] Horizon and Keystone: API Versions and Discovery
- Original Message - > From: "Dolph Mathews" > To: "OpenStack Development Mailing List (not for usage questions)" > > 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 < 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. 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. 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@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 > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Horizon and Keystone: API Versions and Discovery
On Tuesday, October 7, 2014, Adam Young 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
