openstack team mailing list archive

[Adam Young <ayoung@xxxxxxxxxx>]

On 01/31/2013 10:57 PM, Vishvananda Ishaya wrote:
> On Jan 31, 2013, at 6:37 PM, "Ali, Haneef" <haneef.ali@xxxxxx 
> <mailto:haneef.ali@xxxxxx>> wrote:
>
> > 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.
>
> Service catalog is not a constant. That said the only time it is used 
> is when a service needs to proxy a call to another service using the 
> same token. If we had a reasonable way to make requests on behalf of 
> other users we don't really need it as the service could just keep its 
> own catalog and make requests on behalf of the requesting user.

I'm working on it.  It is called "trusts" and there is a WIP posted here:

https://review.openstack.org/#/c/20289/

Blueprint is here:

https://blueprints.launchpad.net/keystone/+spec/trusts

> Vish
>
> > Thanks
> > Haneef
> > *From:*openstack-bounces+haneef.ali=hp.com@xxxxxxxxxxxxxxxxxxx 
> > <mailto:openstack-bounces+haneef.ali=hp.com@xxxxxxxxxxxxxxxxxxx> 
> > [mailto:openstack-bounces+haneef.ali=hp.com@xxxxxxxxxxxxxxxxxxx 
> > <mailto:bounces+haneef.ali=hp.com@xxxxxxxxxxxxxxxxxxx>]*On Behalf 
> > Of*Adam Young
> > *Sent:*Thursday, January 31, 2013 6:25 PM
> > *To:*openstack@xxxxxxxxxxxxxxxxxxx <mailto: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  <https://launchpad.net/%7Eopenstack>
> > Post to     :openstack@xxxxxxxxxxxxxxxxxxx  <mailto:openstack@xxxxxxxxxxxxxxxxxxx>
> > Unsubscribe :https://launchpad.net/~openstack  <https://launchpad.net/%7Eopenstack>
> > More help   :https://help.launchpad.net/ListHelp
> > _______________________________________________
> > Mailing list: https://launchpad.net/~openstack 
> > <https://launchpad.net/%7Eopenstack>
> > Post to     : openstack@xxxxxxxxxxxxxxxxxxx 
> > <mailto:openstack@xxxxxxxxxxxxxxxxxxx>
> > Unsubscribe : https://launchpad.net/~openstack 
> > <https://launchpad.net/%7Eopenstack>
> > More help   : https://help.launchpad.net/ListHelp