Comment 2 for bug 1646765

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to charm-swift-proxy (master)

Reviewed: https://review.openstack.org/406070
Committed: https://git.openstack.org/cgit/openstack/charm-swift-proxy/commit/?id=7c24ae81283710c830ab03f240ec9cc10dccd975
Submitter: Jenkins
Branch: master

commit 7c24ae81283710c830ab03f240ec9cc10dccd975
Author: Frode Nordahl <email address hidden>
Date: Fri Dec 2 12:08:04 2016 +0100

    Fix Keystone v3 auth for swift-proxy

    No need for refresh of proxy-server.conf template for Mitaka. Update
    template for Kilo and later to make use of domain_name and project_name
    parameters instead of domain_id and project_id parameters.

    The current template sets up auth to user in default domain
    but project in service domain. This does not work with service
    domain layout.

    Do not request configured operator_roles roles from Keystone. From
    which roles swift-proxy should accept requests are still configured
    in proxy-server.conf, but requesting and setting up these roles for
    the s3_swift user in Keystone is incorrect behaviour.

    Register required relation data for identity-service immediatelly when
    relation to 'identity-service' exists. Do not postpone registration
    until context is complete which may cause the swift-proxy unit marking
    itself ready while still being in a unconfigured state.

    Add tests to verify configuration and operation of swift-proxy when
    using Keystone v3 auth.

    Change-Id: I8bf182a9256f96af50e4cc37505d9c0ca3d62e47
    Closes-Bug: 1646765