Open Stack

On Wed, May 21, 2014 at 11:32 AM, John Dickinson <me at 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.mathews at gmail.com>
> wrote:
>
> >
> > On Wed, May 21, 2014 at 10:41 AM, John Dickinson <me at 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.fainberg at 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 <ayoung at 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 at lists.openstack.org
> > >> 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
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > 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
>
>
> _______________________________________________
> 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/f42c120c/attachment.html>