<div><br></div><div><div class="gmail_quote">On Mon, Sep 24, 2012 at 4:04 PM, Adam Young <span dir="ltr"><<a href="mailto:ayoung@redhat.com" target="_blank">ayoung@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    <div>The auth_token middleware should be its
      own package from a distribution perspective, but should not be in
      Keystone Client.  <br>
      <br></div></div></blockquote><div><br></div><div>Agree on your first point.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
<div>
      auth_token middle ware now depends on  cryptographic routines that
      are shared with the server side. That is why we cannot simply
      distribute a single auth_token.py file.  <br>
      <br></div></div></blockquote><div><br></div><div><div>Hmm, should we (or can we?) extract common dependencies into a whole new python package (keystonecommon?) that can be consumed by both keystone & auth_token?</div>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><div>
      There is a difference between running the CLI and authenticating
      against Keystone.  Keystone Client is the CLI.  It is for
      administering the Keystone server.  auth_token middleware is for a
      web service to verify tokens against keystone, and to query the
      service catalog.<br>
      <br></div></div></blockquote><div><br></div><div>keystoneclient is really a python API first, and a CLI second. The CLI, end-user authentication, token validation, etc, should all be performed via keystoneclient.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><div>
      For example, glance uses auth_token middleware.  It does not use
      any of the Keystone client code.<br>
      <br></div></div></blockquote><div><br></div><div>auth_token re-implements a subset of keystoneclient's functionality -- I'd like to see auth_token rewritten to consume keystoneclient directly, which would vastly simplify both auth_token and overall maintenance.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><div>
      From a development perspective auth_token is tightly coupled with
      the Keystone server.  As such, the Keystone team should continue
      to maintain code review and approval authority over it, thus it
      should not move in to Openstack common, either.  <br>
      <br></div></div></blockquote><div><br></div><div>Coupled yes, definitely. But I wouldn't describe it as "tight," the last I looked?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><div>
      For packaged distributions,  we should build out of a single
      repository into a proper package breakdown.  The correct package
      breakdown for Keystone is:  server, CLI, auth_token, and common. 
      While the CLI comes from a different git repo, there is no reason
      to split out the other pieces.<br></div></div></blockquote><div><br></div><div>They could/should be different python package namespaces however, which I understand is difficult to do with a single git repo -- due to either gerrit/jenkins?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><div>
      <br>
      auth_token is not the only middleware piece provided by Keystone.
      It is merely the largest and most tightly integrated with the
      other openstack components.  <br>
      <br>
      We should fix the packaging of the autho_token middleware, but
      leave the source code where it currently resides.<div><div><br>
      <br>
      <br>
      <br>
      On 09/24/2012 12:55 PM, heckj wrote:<br>
    </div></div></div><div><div>
    <blockquote type="cite">
      
      Seeing as it's a client for keystone, just like the CLI
      mechanisms, keystoneclient is a good choice - thanks for
      suggesting it Brian!
      <div><br>
      </div>
      <div>I've created a new blueprint - <a href="https://blueprints.launchpad.net/keystone/+spec/authtoken-to-keystoneclient-repo" target="_blank">https://blueprints.launchpad.net/keystone/+spec/authtoken-to-keystoneclient-repo</a></div>



      <div>and we'll review this at the keystone meeting tomorrow (<a href="http://wiki.openstack.org/Meetings/KeystoneMeeting" target="_blank">http://wiki.openstack.org/Meetings/KeystoneMeeting</a>) </div>
      <div><br>
      </div>
      <div>-joe</div>
      <div><br>
        <div><br>
          <div>
            <div>On Sep 24, 2012, at 3:27 AM, Doug Hellmann <<a href="mailto:doug.hellmann@dreamhost.com" target="_blank">doug.hellmann@dreamhost.com</a>>
              wrote:</div>
            <blockquote type="cite">
              <div class="gmail_quote">On Mon, Sep 24, 2012 at 6:13 AM,
                Alan Pevec <span dir="ltr"><<a href="mailto:apevec@gmail.com" target="_blank">apevec@gmail.com</a>></span>
                wrote:<br>
                <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
                  <div>On Mon, Sep 24, 2012 at 10:45 AM,
                    Thierry Carrez <<a href="mailto:thierry@openstack.org" target="_blank">thierry@openstack.org</a>>
                    wrote:<br>
                    > Brian Waldon wrote:<br>
                    >> The auth_token middleware shouldn't live in
                    the Keystone source tree. It is not intended to be
                    used alongside any of the Keystone code as it gets
                    pulled in to every service *but* Keystone. It is
                    super frustrating to have to install all of Keystone
                    just to get this one piece of code. As this
                    middleware is just a client, I am proposing we move
                    it into the existing keystone client library -
                    python-keystoneclient. What are the immediate
                    feelings here?<br>
                    ><br>
                    > Distributions can solve this by creating
                    multiple binary packages from<br>
                    > the same source package,<br>
                    <br>
                  </div>
                  I did that in Fedora for Essex, but it broke post
                  folsom-2 due to new<br>
                  intra-keystone dependencies in auth-token middleware:<br>
                  <a href="https://bugzilla.redhat.com/show_bug.cgi?id=844508" target="_blank">https://bugzilla.redhat.com/show_bug.cgi?id=844508</a><br>
                  <br>
                  There's also an issue with python subpackages sharing
                  python namespace<br>
                  - who owns overlapping __init__.py ?<br>
                </blockquote>
                <div><br>
                </div>
                <div>One common way to solve that is by using a
                  namespace package at the top level.</div>
                <div><br>
                </div>
                <div>Doug</div>
                <div> </div>
                <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
                  Best would be if auth-token is moved out of
                  keystone.middleware, there<br>
                  are stuff imported[1] not required by auth-token.<br>
                  <br>
                  Alan<br>
                  <br>
                  <br>
                  [1] <a href="https://github.com/openstack/keystone/blob/master/keystone/middleware/__init__.py#L17" target="_blank">https://github.com/openstack/keystone/blob/master/keystone/middleware/__init__.py#L17</a><br>



                  <div>
                    <div><br>
                      _______________________________________________<br>
                      OpenStack-dev mailing list<br>
                      <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
                      <a 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>
                    </div>
                  </div>
                </blockquote>
              </div>
              <br>
              _______________________________________________<br>
              OpenStack-dev mailing list<br>
              <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a 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>
          <br>
        </div>
      </div>
      <br>
      <fieldset></fieldset>
      <br>
      <pre>_______________________________________________
OpenStack-dev mailing list
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
    </blockquote>
    <br>
  </div></div></div>

<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a 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>
<br></blockquote></div><br></div>