Re: [openstack-dev] Concerns about the ballooning size of keystone tokens

2014-05-21 Thread Adam Young
On 05/21/2014 11:09 AM, Chuck Thier wrote: There is a review for swift [1] that is requesting to set the max header size to 16k to be able to support v3 keystone tokens. That might be fine if you measure you request rate in requests per minute, but this is continuing to add significant

Re: [openstack-dev] Concerns about the ballooning size of keystone tokens

2014-05-21 Thread Morgan Fainberg
The keystone team is also looking at ways to reduce the data contained in the token. Coupled with the compression, this should get the tokens back down to a reasonable size. Cheers, Morgan Sent via mobile On Wednesday, May 21, 2014, Adam Young ayo...@redhat.com wrote: On 05/21/2014 11:09 AM,

Re: [openstack-dev] Concerns about the ballooning size of keystone tokens

2014-05-21 Thread John Dickinson
Can you explain how PKI info is compressible? I thought it was encrypted, which should mean you can't compress it right? --John On May 21, 2014, at 8:32 AM, Morgan Fainberg morgan.fainb...@gmail.com wrote: The keystone team is also looking at ways to reduce the data contained in the

Re: [openstack-dev] Concerns about the ballooning size of keystone tokens

2014-05-21 Thread Lance Bragstad
John, Adam had a blog post on Compressed Tokens that might help shed a little light on them in general[1]. We also have a blueprint for tracking the work as it gets done[2]. [1] http://adam.younglogic.com/2014/02/compressed-tokens/ [2]

Re: [openstack-dev] Concerns about the ballooning size of keystone tokens

2014-05-21 Thread Dolph Mathews
On Wed, May 21, 2014 at 10:41 AM, John Dickinson m...@not.mn wrote: Can you explain how PKI info is compressible? I thought it was encrypted, which should mean you can't compress it right? They're not encrypted - just signed and then base64 encoded. The JSON (and especially service catalog)

Re: [openstack-dev] Concerns about the ballooning size of keystone tokens

2014-05-21 Thread John Dickinson
Thanks Dolph and Lance for the info and links. What concerns me, in general, about the current length of keystone tokens is that they are unbounded. And the proposed solutions don't change that pattern. My understanding of why PKI tokens are used is so that the system doesn't have to call to

Re: [openstack-dev] Concerns about the ballooning size of keystone tokens

2014-05-21 Thread Kurt Griffiths
adding another ~10kB to each request, just to save a once-a-day call to Keystone (ie uuid tokens) seems to be a really high price to pay for not much benefit. I have the same concern with respect to Marconi. I feel like KPI tokens are fine for control plane APIs, but don’t work so well for

Re: [openstack-dev] Concerns about the ballooning size of keystone tokens

2014-05-21 Thread Morgan Fainberg
This is part of what I was referencing in regards to lightening the data stored in the token. Ideally, we would like to see an ID only token that only contains the basic information to act. Some initial tests show these tokens should be able to clock in under 1k in size. However all the details

Re: [openstack-dev] Concerns about the ballooning size of keystone tokens

2014-05-21 Thread Kurt Griffiths
Dev openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Wednesday, May 21, 2014 at 1:23 PM To: OpenStack Dev openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] Concerns about the ballooning size of keystone tokens

Re: [openstack-dev] Concerns about the ballooning size of keystone tokens

2014-05-21 Thread Dolph Mathews
, May 21, 2014 at 1:23 PM To: OpenStack Dev openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] Concerns about the ballooning size of keystone tokens This is part of what I was referencing in regards to lightening the data stored in the token. Ideally, we would like to see an ID only

Re: [openstack-dev] Concerns about the ballooning size of keystone tokens

2014-05-21 Thread Dolph Mathews
On Wed, May 21, 2014 at 11:32 AM, John Dickinson m...@not.mn wrote: Thanks Dolph and Lance for the info and links. What concerns me, in general, about the current length of keystone tokens is that they are unbounded. And the proposed solutions don't change that pattern. My understanding

Re: [openstack-dev] Concerns about the ballooning size of keystone tokens

2014-05-21 Thread Adam Young
On 05/21/2014 02:00 PM, Kurt Griffiths wrote: adding another ~10kB to each request, just to save a once-a-day call to Keystone (ie uuid tokens) seems to be a really high price to pay for not much benefit. I have the same concern with respect to Marconi. I feel like KPI tokens are fine for

Re: [openstack-dev] Concerns about the ballooning size of keystone tokens

2014-05-21 Thread Adam Young
Dev openstack-dev@lists.openstack.org mailto:openstack-dev@lists.openstack.org Date: Wednesday, May 21, 2014 at 1:23 PM To: OpenStack Dev openstack-dev@lists.openstack.org mailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] Concerns about the ballooning size of keystone tokens

Re: [openstack-dev] Concerns about the ballooning size of keystone tokens

2014-05-21 Thread John Dickinson
: Wednesday, May 21, 2014 at 1:23 PM To: OpenStack Dev openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] Concerns about the ballooning size of keystone tokens This is part of what I was referencing in regards to lightening the data stored in the token. Ideally, we would like to see

Re: [openstack-dev] Concerns about the ballooning size of keystone tokens

2014-05-21 Thread Clint Byrum
Excerpts from John Dickinson's message of 2014-05-21 17:23:02 -0700: On May 21, 2014, at 4:26 PM, Adam Young ayo...@redhat.com wrote: On 05/21/2014 03:36 PM, Kurt Griffiths wrote: Good to know, thanks for clarifying. One thing I’m still fuzzy on, however, is why we want to deprecate

Re: [openstack-dev] Concerns about the ballooning size of keystone tokens

2014-05-21 Thread Adam Young
: [openstack-dev] Concerns about the ballooning size of keystone tokens This is part of what I was referencing in regards to lightening the data stored in the token. Ideally, we would like to see an ID only token that only contains the basic information to act. Some initial tests show these tokens