Users in non-default domain cannot use Blazar

[Jason Anderson]

It is currently assumed that (a) all users are part of the default domain and (b) project users and the admin user are part of the same domain. This causes problems, as trusts cannot be created on behalf of users in a non-default domain (for example, a federated domain.)

[Sam Morrison (sorrison)]

Hi Jason, just wondering if you've made any progress with this?

[Pierre Riteau (priteau)]

Jason submitted https://review.opendev.org/#/c/731586/

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/blazar/+/731586
Committed: https://opendev.org/openstack/blazar/commit/ed238925f912ea1b7ebfa8918b3a29a7bc3f0012
Submitter: "Zuul (22348)"
Branch: master

commit ed238925f912ea1b7ebfa8918b3a29a7bc3f0012
Author: Jason Anderson <email address hidden>
Date: Wed May 27 15:41:35 2020 -0500

    Use built-in oslo context de/serialization

    The oslo context library has built-in mechanisms to deserialize a
    context object from a set of headers; Blazar's built in extension of the
    context class was ignoring several possibly-important pieces of
    information, notably the Keystone domain name.

    To fix, this removes much of the custom logic in the BlazarContext and
    keeps only the two important bits:

    1. A stack of contexts is maintained to allow for nested operations w/
       different sets of credentials
    2. The service_catalog is preserved. It's unclear if this is really
       needed long-term, but some code still relies on it. Also unclear why
       the oslo context doesn't include this when parsing headers.

    Support for multiple domains is included as part of this changeset.
    Before, it was assumed that all users (admins and project users) were
    part of the default domain.

    Closes-Bug: #1881162
    Change-Id: I75fcd97cf7a53d17c909620fcf41a8b5a3699dfa

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/xena
Review: https://review.opendev.org/c/openstack/blazar/+/831508

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/blazar 9.0.0.0rc1 release candidate.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/wallaby
Review: https://review.opendev.org/c/openstack/blazar/+/835059

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/blazar/+/835059
Committed: https://opendev.org/openstack/blazar/commit/80a75392752a54e7e933b8630bca0e38dd5be8fe
Submitter: "Zuul (22348)"
Branch: stable/wallaby

commit 80a75392752a54e7e933b8630bca0e38dd5be8fe
Author: Jason Anderson <email address hidden>
Date: Wed May 27 15:41:35 2020 -0500

    Use built-in oslo context de/serialization

    The oslo context library has built-in mechanisms to deserialize a
    context object from a set of headers; Blazar's built in extension of the
    context class was ignoring several possibly-important pieces of
    information, notably the Keystone domain name.

    To fix, this removes much of the custom logic in the BlazarContext and
    keeps only the two important bits:

    1. A stack of contexts is maintained to allow for nested operations w/
       different sets of credentials
    2. The service_catalog is preserved. It's unclear if this is really
       needed long-term, but some code still relies on it. Also unclear why
       the oslo context doesn't include this when parsing headers.

    Support for multiple domains is included as part of this changeset.
    Before, it was assumed that all users (admins and project users) were
    part of the default domain.

    Closes-Bug: #1881162
    Change-Id: I75fcd97cf7a53d17c909620fcf41a8b5a3699dfa
    (cherry picked from commit ed238925f912ea1b7ebfa8918b3a29a7bc3f0012)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/blazar/+/831508
Committed: https://opendev.org/openstack/blazar/commit/fc4008382428bba53fbbed22c639ef98167c5f3c
Submitter: "Zuul (22348)"
Branch: stable/xena

commit fc4008382428bba53fbbed22c639ef98167c5f3c
Author: Jason Anderson <email address hidden>
Date: Wed May 27 15:41:35 2020 -0500

    Use built-in oslo context de/serialization

    The oslo context library has built-in mechanisms to deserialize a
    context object from a set of headers; Blazar's built in extension of the
    context class was ignoring several possibly-important pieces of
    information, notably the Keystone domain name.

    To fix, this removes much of the custom logic in the BlazarContext and
    keeps only the two important bits:

    1. A stack of contexts is maintained to allow for nested operations w/
       different sets of credentials
    2. The service_catalog is preserved. It's unclear if this is really
       needed long-term, but some code still relies on it. Also unclear why
       the oslo context doesn't include this when parsing headers.

    Support for multiple domains is included as part of this changeset.
    Before, it was assumed that all users (admins and project users) were
    part of the default domain.

    Closes-Bug: #1881162
    Change-Id: I75fcd97cf7a53d17c909620fcf41a8b5a3699dfa
    (cherry picked from commit ed238925f912ea1b7ebfa8918b3a29a7bc3f0012)

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/blazar 7.0.1 release.

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/blazar 8.0.1 release.