<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 08/10/2015 07:46 AM, Matthew
      Mosesohn wrote:<br>
    </div>
    <blockquote
cite="mid:CA+CvLD6_7SBkLuJ_erK0UiRMiRwMDvnds14TdmkN3WUttSZGvQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div>
          <div>
            <div>Sorry to everyone for bringing up this old thread, but
              it seems we may need more openstackclient/keystone experts
              to settle this.<br>
              <br>
            </div>
            I'm referring to the comments in <a moz-do-not-send="true"
              href="https://review.openstack.org/#/c/207873/">https://review.openstack.org/#/c/207873/</a><br>
          </div>
          Specifically comments from Richard Megginson and Gilles
          Dubreuil indicating openstackclient behavior for v3 keystone
          API.<br>
          <br>
          <br>
        </div>
        <div>A few items seem to be under dispute:<br>
        </div>
        <div>1 - Keystone should be able to accept v3 requests at <a
            moz-do-not-send="true" href="http://keystone-server:5000/"><a class="moz-txt-link-freetext" href="http://keystone-server:5000/">http://keystone-server:5000/</a></a><br>
        </div>
      </div>
    </blockquote>
    <br>
    I don't think so.  Keystone requires the version suffix "/v2.0" or
    "/v3".<br>
    <br>
    <blockquote
cite="mid:CA+CvLD6_7SBkLuJ_erK0UiRMiRwMDvnds14TdmkN3WUttSZGvQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div>2 - openstackclient should be able to interpret v3 requests
          and append "v3/" to OS_AUTH_URL=<a moz-do-not-send="true"
            href="http://keystone-server.5000/">http://keystone-server.5000/</a>
          or rewrite the URL if it is set as OS_AUTH_URL=<a
            moz-do-not-send="true" href="http://keystone-server.5000/"><a class="moz-txt-link-freetext" href="http://keystone-server.5000/">http://keystone-server.5000/</a></a><br>
        </div>
      </div>
    </blockquote>
    <br>
    It does, if it can determine from the given authentication arguments
    if it can do v3 or v2.0.<br>
    <br>
    <blockquote
cite="mid:CA+CvLD6_7SBkLuJ_erK0UiRMiRwMDvnds14TdmkN3WUttSZGvQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div>3 - All deployments require /etc/keystone/keystone.conf
          with a token (and not simply use openrc for creating
          additional endpoints, users, etc beyond keystone itself and an
          admin user)<br>
        </div>
      </div>
    </blockquote>
    <br>
    No.  What I said about this issue was "Most people using
    puppet-keystone, and realizing Keystone resources on nodes that are
    not the Keystone node, put a /etc/keystone/keystone.conf on that
    node with the admin_token in it."<br>
    <br>
    That doesn't mean the deployment requires
    /etc/keystone/keystone.conf.  It should be possible to realize
    Keystone resources on non-Keystone nodes by using ENV or openrc or
    other means.<br>
    <br>
    <blockquote
cite="mid:CA+CvLD6_7SBkLuJ_erK0UiRMiRwMDvnds14TdmkN3WUttSZGvQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div><br>
        </div>
        <div>I believe it should be possible to set v2.0 keystone
          OS_AUTH_URL in openrc and puppet-keystone +
          puppet-openstacklib should be able to make v3 requests
          sensibly by manipulating the URL.<br>
        </div>
      </div>
    </blockquote>
    <br>
    Yes.  Because for the puppet-keystone resource providers, they are
    coded to a specific version of the api, and therefore need to be
    able to set/override the OS_IDENTITY_API_VERSION and the version
    suffix in the URL.<br>
    <br>
    <blockquote
cite="mid:CA+CvLD6_7SBkLuJ_erK0UiRMiRwMDvnds14TdmkN3WUttSZGvQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div>Additionally, creating endpoints/users/roles shouldbe
          possible via openrc alone.</div>
      </div>
    </blockquote>
    <br>
    Yes.<br>
    <br>
    <blockquote
cite="mid:CA+CvLD6_7SBkLuJ_erK0UiRMiRwMDvnds14TdmkN3WUttSZGvQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div>It's not possible to write single node tests that can
          demonstrate this functionality, which is why it probably went
          undetected for so long.<br>
        </div>
      </div>
    </blockquote>
    <br>
    And since this is supported, we need tests for this.<br>
    <blockquote
cite="mid:CA+CvLD6_7SBkLuJ_erK0UiRMiRwMDvnds14TdmkN3WUttSZGvQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div><br>
        </div>
        <div>If anyone can speak up on these items, it could help
          influence the outcome of this patch. <br>
          <br>
        </div>
        <div>Thank you for your time.<br>
          <br>
        </div>
        <div>Best Regards,<br>
        </div>
        <div>Matthew Mosesohn<br>
        </div>
      </div>
      <div class="gmail_extra"><br>
        <div class="gmail_quote">On Fri, Jul 31, 2015 at 6:32 PM, Rich
          Megginson <span dir="ltr"><<a moz-do-not-send="true"
              href="mailto:rmeggins@redhat.com" target="_blank">rmeggins@redhat.com</a>></span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex"><span
              class="">On 07/31/2015 07:18 AM, Matthew Mosesohn wrote:<br>
              <blockquote class="gmail_quote" style="margin:0 0 0
                .8ex;border-left:1px #ccc solid;padding-left:1ex">
                Jesse, thanks for raising this. Like you, I should just
                track upstream<br>
                and wait for full V3 support.<br>
                <br>
                I've taken the quickest approach and written fixes to<br>
                puppet-openstacklib and puppet-keystone:<br>
                <a moz-do-not-send="true"
                  href="https://review.openstack.org/#/c/207873/"
                  rel="noreferrer" target="_blank">https://review.openstack.org/#/c/207873/</a><br>
                <a moz-do-not-send="true"
                  href="https://review.openstack.org/#/c/207890/"
                  rel="noreferrer" target="_blank">https://review.openstack.org/#/c/207890/</a><br>
                <br>
                and again to Fuel-Library:<br>
                <a moz-do-not-send="true"
                  href="https://review.openstack.org/#/c/207548/1"
                  rel="noreferrer" target="_blank">https://review.openstack.org/#/c/207548/1</a><br>
                <br>
                I greatly appreciate the quick support from the
                community to find an<br>
                appropriate solution. Looks like I'm just using a weird
                edge case<br>
                where we're creating users on a separate node from where
                keystone is<br>
                installed and it never got thoroughly tested, but I'm
                happy to fix<br>
                bugs where I can.<br>
              </blockquote>
              <br>
            </span>
            Most puppet deployments either realize all keystone
            resources on the keystone node, or drop an
            /etc/keystone/keystone.conf with admin token onto
            non-keystone nodes where additional keystone resources need
            to be realized.
            <div class="HOEnZb">
              <div class="h5"><br>
                <br>
                <blockquote class="gmail_quote" style="margin:0 0 0
                  .8ex;border-left:1px #ccc solid;padding-left:1ex">
                  <br>
                  -Matthew<br>
                  <br>
                  On Fri, Jul 31, 2015 at 3:54 PM, Jesse Pretorius<br>
                  <<a moz-do-not-send="true"
                    href="mailto:jesse.pretorius@gmail.com"
                    target="_blank">jesse.pretorius@gmail.com</a>>
                  wrote:<br>
                  <blockquote class="gmail_quote" style="margin:0 0 0
                    .8ex;border-left:1px #ccc solid;padding-left:1ex">
                    With regards to converting all services to use
                    Keystone v3 endpoints, note<br>
                    the following:<br>
                    <br>
                    1) swift-dispersion currently does not support
                    consuming Keystone v3<br>
                    endpoints [1]. There is a patch merged to master [2]
                    to fix that, but a<br>
                    backport to kilo is yet to be done.<br>
                    2) Each type (internal, admin, public) of endpoint
                    created with the Keystone<br>
                    v3 API has its own unique id, unlike with the v2 API
                    where they're all<br>
                    created with a single ID. This results in the
                    keystone client being unable<br>
                    to read the catalog created via the v3 API when
                    querying via the v2 API. The<br>
                    solution is to use the openstack client and to use
                    the v3 API but this<br>
                    obviously needs to be noted for upgrade impact and
                    operators.<br>
                    3) When glance is setup to use swift as a back-end,
                    glance_store is unable<br>
                    to authenticate to swift when the endpoint it uses
                    is a v3 endpoint. There<br>
                    is a review to master in progress [3] to fix this
                    which is unlikely to make<br>
                    it into kilo.<br>
                    <br>
                    We (the openstack-ansible/os-ansible-deployment
                    project) are tracking these<br>
                    issues and doing tests to figure out all the bits.
                    These are the bugs we've<br>
                    hit so far. Also note that there is a WIP patch to
                    gate purely on Keystone<br>
                    v3 API's which is planned to become voting
                    (hopefully) by the end of this<br>
                    cycle.<br>
                    <br>
                    [1] <a moz-do-not-send="true"
                      href="https://bugs.launchpad.net/swift/+bug/1468374"
                      rel="noreferrer" target="_blank">https://bugs.launchpad.net/swift/+bug/1468374</a><br>
                    [2] <a moz-do-not-send="true"
                      href="https://review.openstack.org/195131"
                      rel="noreferrer" target="_blank">https://review.openstack.org/195131</a><br>
                    [3] <a moz-do-not-send="true"
                      href="https://review.openstack.org/193422"
                      rel="noreferrer" target="_blank">https://review.openstack.org/193422</a><br>
                    <br>
__________________________________________________________________________<br>
                    OpenStack Development Mailing List (not for usage
                    questions)<br>
                    Unsubscribe: <a moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
                      rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
                    <a moz-do-not-send="true"
                      href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
                      rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
                    <br>
                  </blockquote>
__________________________________________________________________________<br>
                  OpenStack Development Mailing List (not for usage
                  questions)<br>
                  Unsubscribe: <a moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
                    rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
                  <a moz-do-not-send="true"
                    href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
                    rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
                </blockquote>
                <br>
                <br>
__________________________________________________________________________<br>
                OpenStack Development Mailing List (not for usage
                questions)<br>
                Unsubscribe: <a moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
                  rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
                <a moz-do-not-send="true"
                  href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
                  rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
              </div>
            </div>
          </blockquote>
        </div>
        <br>
      </div>
      <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>