openstack team mailing list archive

["Ali, Haneef" <haneef.ali@xxxxxx>]

Isn't  signed token an optional feature?  If so validateToken is going to be a high frequency call.  Also  "Service Catalog" is a constant, the services can  cache it.  It doesn't need to be part of validateToken.

Thanks
Haneef

From: openstack-bounces+haneef.ali=hp.com@xxxxxxxxxxxxxxxxxxx [mailto:openstack-bounces+haneef.ali=hp.com@xxxxxxxxxxxxxxxxxxx] On Behalf Of Adam Young
Sent: Thursday, January 31, 2013 6:25 PM
To: openstack@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Openstack] [keystone] Why are we returing such a big payload in validate token?

On 01/31/2013 07:44 PM, Ali, Haneef wrote:
Hi,

As of now  v3  validateToken response has "tokens, service catalog, users, project , roles and  domains.  (i.e)  Except for groups we are returning everything.  We also discussed about the possibility of 100s of endpoints.  ValidateToken is supposed to be a high frequency call .    This is

Validate token should not going  be a high frequency call.  The information is encapsulated inside the signed token for just that reason.

I would agree with the sentiment, however, that we are cramming a lot of info into the token.  TOkens should be scoped much, much more finely: by default one service or endpoint, and one tenant.

The only thing that should require the full service catalog is the initial request of an unsigned token, and that should merely go back to the client.


going to be a huge performance impact . What is the use case  for such a big payload  when compared with v2?

If a service needs catalog , then the service can always ask for the catalog.

Thanks
Haneef




_______________________________________________

Mailing list: https://launchpad.net/~openstack

Post to     : openstack@xxxxxxxxxxxxxxxxxxx<mailto:openstack@xxxxxxxxxxxxxxxxxxx>

Unsubscribe : https://launchpad.net/~openstack

More help   : https://help.launchpad.net/ListHelp