Re: [openstack-dev] Horizon and Keystone: API Versions and Discovery

2014-10-21 Thread Jamie Lennox


- Original Message -
 From: Dolph Mathews dolph.math...@gmail.com
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@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  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

2014-10-21 Thread Dean Troyer
On Tue, Oct 21, 2014 at 8:34 AM, Jamie Lennox jamielen...@redhat.com
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

2014-10-20 Thread Jamie Lennox


- 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. 

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

2014-10-20 Thread Dolph Mathews
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.



 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

2014-10-07 Thread Dolph Mathews
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