<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 05/21/2014 03:36 PM, Kurt Griffiths
      wrote:<br>
    </div>
    <blockquote cite="mid:CFA262B8.21670%25kurt.griffiths@rackspace.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      <div>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...</div>
    </blockquote>
    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.<br>
    <br>
    <br>
    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.<br>
    <br>
    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.  <br>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    <br>
    <br>
    <br>
    <br>
    <br>
    <blockquote cite="mid:CFA262B8.21670%25kurt.griffiths@rackspace.com"
      type="cite">
      <div><br>
      </div>
      <span id="OLK_SRC_BODY_SECTION">
        <div style="font-family:Calibri; font-size:11pt;
          text-align:left; color:black; BORDER-BOTTOM: medium none;
          BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT:
          0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid;
          BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
          <span style="font-weight:bold">From: </span>Morgan Fainberg
          <<a moz-do-not-send="true"
            href="mailto:morgan.fainberg@gmail.com">morgan.fainberg@gmail.com</a>><br>
          <span style="font-weight:bold">Reply-To: </span>OpenStack Dev
          <<a moz-do-not-send="true"
            href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
          <span style="font-weight:bold">Date: </span>Wednesday, May
          21, 2014 at 1:23 PM<br>
          <span style="font-weight:bold">To: </span>OpenStack Dev <<a
            moz-do-not-send="true"
            href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
          <span style="font-weight:bold">Subject: </span>Re:
          [openstack-dev] Concerns about the ballooning size of keystone
          tokens<br>
        </div>
        <div><br>
        </div>
        <div>
          <div>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. 
            <div><br>
            </div>
            <div>I hope to have this token change available during Juno
              development cycle. <br>
              <div><br>
              </div>
              <div>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. </div>
              <div><br>
              </div>
              <div>Cheers,</div>
              <div>Morgan</div>
              <div><br>
              </div>
              <div>Sent via mobile <span></span><br>
                <div><br>
                  On Wednesday, May 21, 2014, Kurt Griffiths <<a
                    moz-do-not-send="true"
                    href="mailto:kurt.griffiths@rackspace.com">kurt.griffiths@rackspace.com</a>>
                  wrote:<br>
                  <blockquote class="gmail_quote" style="margin:0 0 0
                    .8ex;border-left:1px #ccc solid;padding-left:1ex">
                    > adding another ~10kB to each request, just to
                    save a once-a-day call to<br>
                    >Keystone (ie uuid tokens) seems to be a really
                    high price to pay for not<br>
                    >much benefit.<br>
                    <br>
                    I have the same concern with respect to Marconi. I
                    feel like KPI tokens<br>
                    are fine for control plane APIs, but don’t work so
                    well for high-volume<br>
                    data APIs where every KB counts.<br>
                    <br>
                    Just my $0.02...<br>
                    <br>
                    --Kurt<br>
                    <br>
                    _______________________________________________<br>
                    OpenStack-dev mailing list<br>
                    <a moz-do-not-send="true" href="javascript:;"
                      onclick="_e(event, 'cvml',
                      'OpenStack-dev@lists.openstack.org')">OpenStack-dev@lists.openstack.org</a><br>
                    <a moz-do-not-send="true"
                      href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
                      target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
                  </blockquote>
                </div>
              </div>
            </div>
          </div>
        </div>
      </span>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
OpenStack-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>