[Openstack] [keystone] Why are we returing such a big payload in validate token?
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 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@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [keystone] Why are we returing such a big payload in validate token?
+1000 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 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@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
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@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [keystone] Why are we returing such a big payload in validate token?
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@lists.launchpad.net [mailto:openstack-bounces+haneef.ali=hp@lists.launchpad.net] On Behalf Of Adam Young Sent: Thursday, January 31, 2013 6:25 PM To: openstack@lists.launchpad.net 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@lists.launchpad.netmailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [keystone] Why are we returing such a big payload in validate token?
On Jan 31, 2013, at 6:37 PM, Ali, Haneef haneef@hp.com 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. Vish Thanks Haneef From: openstack-bounces+haneef.ali=hp@lists.launchpad.net [mailto:openstack-bounces+haneef.ali=hp@lists.launchpad.net] On Behalf Of Adam Young Sent: Thursday, January 31, 2013 6:25 PM To: openstack@lists.launchpad.net 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@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [keystone] Why are we returing such a big payload in validate token?
On 01/31/2013 10:57 PM, Vishvananda Ishaya wrote: On Jan 31, 2013, at 6:37 PM, Ali, Haneef haneef@hp.com mailto:haneef@hp.com 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@lists.launchpad.net mailto:openstack-bounces+haneef.ali=hp@lists.launchpad.net [mailto:openstack-bounces+haneef.ali=hp@lists.launchpad.net mailto:bounces+haneef.ali=hp@lists.launchpad.net]*On Behalf Of*Adam Young *Sent:*Thursday, January 31, 2013 6:25 PM *To:*openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net *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@lists.launchpad.net mailto:openstack@lists.launchpad.net 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@lists.launchpad.net mailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
