<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <p>Worth noting, I have been playing with 3.2.0 and the same problem
      persists in our deployment which is running a variant of the old
      default keystone policy.<br>
    </p>
    <br>
    <div class="moz-cite-prefix">On 22/09/16 10:34, Adrian Turjak wrote:<br>
    </div>
    <blockquote
      cite="mid:d4089d9f-9759-1a69-6e32-2f5e6a14a17f@catalyst.net.nz"
      type="cite">
      <meta content="text/html; charset=windows-1252"
        http-equiv="Content-Type">
      That commit doesn't really address the problem in question though.<br>
      <br>
      The problem is that the OpenStack client assumes the "get user"
      policy in Keystone allows you to get your own user, which it
      didn't until Newton, and thus a lot of deployments probably are
      using the default policy or some variant thereof. Ours is included
      in this list, and while I am working on getting our Keystone
      policy updated to match that assumption, it makes sense to fix the
      issue in the openstackclient for anyone else running into this
      problem.<br>
      <br>
      What I'd like to do is one of these two options:<br>
      - "openstack user project list", a command which will get your id
      from your authed token and used it directly with the
      keystoneclient as such:
      "keystoneclient.projects.list(user='<my_user_id>')" which
      will pipe the call correctly to: "/v3/users/{user_id}/projects"<br>
      - or update "openstack project list" with a "--auth-user" flag
      that ignores all other options and directly filters the project
      list by your token's user id. This type of option is already
      present in the "role assignment list" command. From a UX
      standpoint part of me feels that project list should default to
      --auth-user if your token doesn't have admin roles, but I'm not
      sure how easy that would be to do.<br>
      <br>
      There may be other commands that fall over due to a unneeded
      resource_find call to get user, but I haven't explored those too
      much yet. Chances are any non-admin command which can be filtered
      by user and does a resource find first we fall over on anything
      < Newton.<br>
      <br>
      <div class="moz-cite-prefix">On 22/09/16 06:31, Steve Martinelli
        wrote:<br>
      </div>
      <blockquote
cite="mid:CAHc_MXH+fG+39OamGO1H9M2h3Eah0s42Ud=DW0PnNXu1v1GJqA@mail.gmail.com"
        type="cite">
        <div dir="ltr">
          <div class="gmail_extra">
            <div class="gmail_quote">On Wed, Sep 21, 2016 at 1:04 PM,
              Dolph Mathews <span dir="ltr"><<a
                  moz-do-not-send="true"
                  href="mailto:dolph.mathews@gmail.com" target="_blank">dolph.mathews@gmail.com</a>></span>
              wrote:<br>
              <blockquote class="gmail_quote" style="margin:0px 0px 0px
                0.8ex;border-left:1px solid
                rgb(204,204,204);padding-left:1ex">
                <div dir="ltr">
                  <div class="gmail_quote"><span class="gmail-">
                      <div dir="ltr"><br>
                      </div>
                    </span>
                    <div>I should also express a +1 for something along
                      the lines of your original proposal. I'd go so far
                      as to suggest that `openstack show user` (without
                      a user ID or name as an argument) should return
                      "me" (the authenticated user), as I think that'd
                      be a better user experience.</div>
                  </div>
                </div>
              </blockquote>
              <div><br>
              </div>
              <div>That should be fixed in openstackclient 3.0.0 -- <a
                  moz-do-not-send="true"
href="https://github.com/openstack/python-openstackclient/commit/337d013c94378a4b3f0e8f90e4f5bd745448658f">https://github.com/openstack/python-openstackclient/commit/337d013c94378a4b3f0e8f90e4f5bd745448658f</a></div>
              <div><br>
              </div>
            </div>
          </div>
        </div>
        <br>
        <fieldset class="mimeAttachmentHeader"></fieldset>
        <br>
        <pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a moz-do-not-send="true" 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>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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>