Open Stack

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 UUID tokens in the first 
> place? I'm just trying to understand the history here...
Because they are wasteful, and because they are the chattiest part of 
OpenStack.  I can go into it in nauseating detail if you really want, 
including the plans for future enhancements and the weaknesses of bearer 
tokens.


A token is nothing more than a snap shot of the data you get from 
Keystone distributed.  It is stored in Memcached and in the Horizon 
session uses the hash of it for a key.

You can do the same thing.  Once you know the token has been transferred 
once to a service, assuming that service has caching on, you can pass 
the hash of the key instead of the whole thing.

Actually, you can do that up front, as auth_token middleware will just 
default to an online lookup. However, we are planning on moving to 
ephemeral tokens (not saved in the database) and an online lookup won't 
be possible with those.  The people that manage Keystone will be happy 
with that, and forcing an online lookup will make them sad.

Hash is MD5 up through what is released in Icehouse.  The next version 
of auth_token middleware will support a configurable algorithm.  The 
default should be updated to sha256 in the near future.






>
> From: Morgan Fainberg <morgan.fainberg at gmail.com 
> <mailto:morgan.fainberg at gmail.com>>
> Reply-To: OpenStack Dev <openstack-dev at lists.openstack.org 
> <mailto:openstack-dev at lists.openstack.org>>
> Date: Wednesday, May 21, 2014 at 1:23 PM
> To: OpenStack Dev <openstack-dev at lists.openstack.org 
> <mailto:openstack-dev at 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" 
> 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 are not fully defined yet. Coupled with this 
> data reduction there will be explicit definitions of the data that is 
> meant to go into the tokens. Some of the data we have now is a result 
> of convenience of accessing the data.
>
> I hope to have this token change available during Juno development cycle.
>
> There is a lot of work to be done to ensure this type of change goes 
> smoothly. But this is absolutely on the list of things we would like 
> to address.
>
> Cheers,
> Morgan
>
> Sent via mobile
>
> On Wednesday, May 21, 2014, Kurt Griffiths 
> <kurt.griffiths at rackspace.com <mailto:kurt.griffiths at rackspace.com>> 
> 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 control plane APIs, but don't work so well for
>     high-volume
>     data APIs where every KB counts.
>
>     Just my $0.02...
>
>     --Kurt
>
>     _______________________________________________
>     OpenStack-dev mailing list
>     OpenStack-dev at lists.openstack.org <javascript:;>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140521/3b7ba6de/attachment.html>