On 05/21/2014 08:59 PM, Clint Byrum wrote:
Excerpts from John Dickinson's message of 2014-05-21 17:23:02 -0700:
On May 21, 2014, at 4:26 PM, Adam Young 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
ck.
What communication is most impacted by the large token size? Is it
fetching out images for a web page or something like that?
From: Morgan Fainberg
Reply-To: OpenStack Dev
Date: Wednesday, May 21, 2014 at 1:23 PM
To: OpenStack Dev
Subject: Re: [openstack-dev] Concerns abo
Excerpts from John Dickinson's message of 2014-05-21 17:23:02 -0700:
>
> On May 21, 2014, at 4:26 PM, Adam Young 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 use of UU
, not committing to
a patch).
>
>
>
>
>
>
>>
>> From: Morgan Fainberg
>> Reply-To: OpenStack Dev
>> Date: Wednesday, May 21, 2014 at 1:23 PM
>> To: OpenStack Dev
>> Subject: Re: [openstack-dev] Concerns about the ballooning size of k
ev <mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, May 21, 2014 at 1:23 PM
To: OpenStack Dev <mailto: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 reg
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 contro
On Wed, May 21, 2014 at 11:32 AM, John Dickinson 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 of wh
2014 at 1:23 PM
> To: OpenStack Dev
> 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" token
nstack-dev@lists.openstack.org>>
Date: Wednesday, May 21, 2014 at 1:23 PM
To: OpenStack Dev
mailto: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 d
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
a
> 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 hig
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 K
On Wed, May 21, 2014 at 10:41 AM, John Dickinson 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) is compres
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] https://blueprints.launchpad.net/keystone/+spec/compress-tok
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 wrote:
> The keystone team is also looking at ways to reduce the data contained in the
> token. Coupled with the co
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 wrote:
> On 05/21/2014 11:09 AM, Chuck Thier wrot
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 overhea
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 overhead to swift. Even if you *only* have
10,000 req
18 matches
Mail list logo
