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 of why PKI tokens are used is so that the system doesn't > have to call to Keystone to authorize the request. This reduces the load on > Keystone, but it adds significant overhead for every API request. > > Keystone's first system was to use UUID bearer tokens. These are fixed > length, small, cacheable, and require a call to Keystone once per cache > period. > > Moving to PKI tokens, we now have multi-kB headers that significantly > increase the size of each request. Swift deployers commonly have small > objects on the order of <50kB, so 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. > > The other benefit to PKI tokens is that services can make calls to other > systems on behalf of the user (eg nova can call cinder for the user). This > is great, but it's not the only usage pattern in OpenStack projects, and > therefore I don't like optimizing for it at the expense of other patterns. > > In addition to PKI tokens (ie signed+encoded service catalogs), I'd like > to see Keystone support and remain committed to fixed-length bearer tokens > or a signed-with-shared-secret auth mechanism (a la AWS). > This is a fantastic argument in favor of UUID today. PKI will likely never be fixed-length, but hopefully we can continue making them smaller such that this argument might carry substantially less weight someday. > > --John > > > > > On May 21, 2014, at 9:09 AM, Dolph Mathews <dolph.math...@gmail.com> > wrote: > > > > > 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) is compressible prior to encoding. > > > > > > > > --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 > > > _______________________________________________ > 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