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-tokens 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? > > > --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 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, 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 overhead to swift. Even if you *only* have > 10,000 requests/sec to your swift cluster, an 8k token is adding almost > 80MB/sec of bandwidth. This will seem to be equally bad (if not worse) for > services like marconi. > >> > >> When PKI tokens were first introduced, we raised concerns about the > unbounded size of of the token in the header, and were told that uuid style > tokens would still be usable, but all I heard at the summit, was to not use > them and PKI was the future of all things. > >> > >> At what point do we re-evaluate the decision to go with pki tokens, and > that they may not be the best idea for apis like swift and marconi? > > > > Keystone tokens were slightly shrunk at the end of the last release > cycle by removing unnecessary data from each endpoint entry. > > > > Compressed PKI tokens are enroute and will be much smaller. > > > >> > >> Thanks, > >> > >> -- > >> Chuck > >> > >> [1] https://review.openstack.org/#/c/93356/ > >> > >> > >> _______________________________________________ > >> OpenStack-dev mailing list > >> > >> OpenStack-dev@lists.openstack.org > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
