On 08/10/2015 07:46 AM, Matthew Mosesohn wrote:
Sorry to everyone for bringing up this old thread, but it seems we may need more openstackclient/keystone experts to settle this.

I'm referring to the comments in https://review.openstack.org/#/c/207873/
Specifically comments from Richard Megginson and Gilles Dubreuil indicating openstackclient behavior for v3 keystone API.


A few items seem to be under dispute:
1 - Keystone should be able to accept v3 requests at http://keystone-server:5000/

I don't think so.  Keystone requires the version suffix "/v2.0" or "/v3".

2 - openstackclient should be able to interpret v3 requests and append "v3/" to OS_AUTH_URL=http://keystone-server.5000/ or rewrite the URL if it is set as OS_AUTH_URL=http://keystone-server.5000/

It does, if it can determine from the given authentication arguments if it can do v3 or v2.0.

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)

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."

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.


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.

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.

Additionally, creating endpoints/users/roles shouldbe possible via openrc alone.

Yes.

It's not possible to write single node tests that can demonstrate this functionality, which is why it probably went undetected for so long.

And since this is supported, we need tests for this.

If anyone can speak up on these items, it could help influence the outcome of this patch.

Thank you for your time.

Best Regards,
Matthew Mosesohn

On Fri, Jul 31, 2015 at 6:32 PM, Rich Megginson <rmegg...@redhat.com <mailto:rmegg...@redhat.com>> wrote:

    On 07/31/2015 07:18 AM, Matthew Mosesohn wrote:

        Jesse, thanks for raising this. Like you, I should just track
        upstream
        and wait for full V3 support.

        I've taken the quickest approach and written fixes to
        puppet-openstacklib and puppet-keystone:
        https://review.openstack.org/#/c/207873/
        https://review.openstack.org/#/c/207890/

        and again to Fuel-Library:
        https://review.openstack.org/#/c/207548/1

        I greatly appreciate the quick support from the community to
        find an
        appropriate solution. Looks like I'm just using a weird edge case
        where we're creating users on a separate node from where
        keystone is
        installed and it never got thoroughly tested, but I'm happy to fix
        bugs where I can.


    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.



        -Matthew

        On Fri, Jul 31, 2015 at 3:54 PM, Jesse Pretorius
        <jesse.pretor...@gmail.com <mailto:jesse.pretor...@gmail.com>>
        wrote:

            With regards to converting all services to use Keystone v3
            endpoints, note
            the following:

            1) swift-dispersion currently does not support consuming
            Keystone v3
            endpoints [1]. There is a patch merged to master [2] to
            fix that, but a
            backport to kilo is yet to be done.
            2) Each type (internal, admin, public) of endpoint created
            with the Keystone
            v3 API has its own unique id, unlike with the v2 API where
            they're all
            created with a single ID. This results in the keystone
            client being unable
            to read the catalog created via the v3 API when querying
            via the v2 API. The
            solution is to use the openstack client and to use the v3
            API but this
            obviously needs to be noted for upgrade impact and operators.
            3) When glance is setup to use swift as a back-end,
            glance_store is unable
            to authenticate to swift when the endpoint it uses is a v3
            endpoint. There
            is a review to master in progress [3] to fix this which is
            unlikely to make
            it into kilo.

            We (the openstack-ansible/os-ansible-deployment project)
            are tracking these
            issues and doing tests to figure out all the bits. These
            are the bugs we've
            hit so far. Also note that there is a WIP patch to gate
            purely on Keystone
            v3 API's which is planned to become voting (hopefully) by
            the end of this
            cycle.

            [1] https://bugs.launchpad.net/swift/+bug/1468374
            [2] https://review.openstack.org/195131
            [3] https://review.openstack.org/193422

            
__________________________________________________________________________
            OpenStack Development Mailing List (not for usage questions)
            Unsubscribe:
            openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
            
<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
            http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

        
__________________________________________________________________________
        OpenStack Development Mailing List (not for usage questions)
        Unsubscribe:
        openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
        <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
        http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



    __________________________________________________________________________
    OpenStack Development Mailing List (not for usage questions)
    Unsubscribe:
    openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
    <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
    http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to