Open Stack

On 6 April 2015 at 21:27, David Kranz <dkranz at redhat.com> wrote:
> On 04/06/2015 03:14 PM, Matthew Treinish wrote:
>
> On Mon, Apr 06, 2015 at 02:25:14PM -0400, David Kranz wrote:
>
> There have been a number of changes in tempest recently that seem to
> coordinate with devstack that are a bit unclear.
>
> Well, the issue was that before tempest was making all sorts of incorrect
> implicit assumptions about the underlying configuration. As part of the test
> accounts part 2 bp [1] we needed to correct these and make things more
> explicit
> which resulted in a number of changes around the configuration in tempest.
>
> FWIW, I push to have detailed commit messages to try and make it clear from
> the
> git log and explain the rationale behind changes like this.
>
> The following values are defined in tempest config as defaults:
>
> [auth]
> # Roles to assign to all users created by tempest (list value)
> #tempest_roles =
>
> So this option is used to set roles on every user created by tenant
> isolation.
> Outside of tenant isolation this option does nothing.
>
> [object-storage]
> # Role to add to users created for swift tests to enable creating
> # containers (string value)
> #operator_role = Member
>
> [orchestration]
> # Role required for users to be able to manage stacks (string value)
> #stack_owner_role = heat_stack_owner
>
> These are the values created in tempest.conf by devstack:
>
> [auth]
>
> tempest_roles = Member
>
>
> [orchestration]
> stack_owner_role = _member_
>
> So a couple of questions.
>
> Why do we have Member and _member_, and what is the difference supposed to
> be?
>
> IIRC _member_ is the default role with keystone v3 which is used to show
> membership in a project. I'm sure Jamie or Morgan will correct me if I'm
> wrong
> on this.
>
> Experimentally, it seems that the tempest roles cannot be empty, so why is
> that the default?
>
> So, I'm surprised by this, the tests which require the role Member to be set
> on
> the created users should be specifically requesting this now. (as part of
> the
> test accounts bp we had to make these expectations explicit) It should only
> be
> required for the swift tests that do container manipulation.[2] I'm curious
> to
> see what you're hitting here. The one thing is from the git log there may be
> an interaction here depending on the keystone api version you're using. [3]
> My
> guess is that it's needed for using keystone v2 in a v3 env, or vice versa,
> but
> I'm sure Andrea will chime in if this is wrong.
>
> Seems right to me. I should have said it is the identity v3 tests that fail
> if you leave the default for tempest_roles. It does seem that Member is
> related to swift tests and it would be less confusing if this were called
> SwiftOperator instead of Member. The only hardcoded reference to Member in
> tempest now is in javelin and that is going to be removed
> https://review.openstack.org/#/c/169108/
>
> Andrea, can you explain why the role that is required in the tempest_roles
> is Member?
> If this is really the way it needs to be we should have this as the default
> in tempest.conf rather than having devstack always set it, no?
>
>  -David
>

Using identity v2, a user is given a role on the tenant automatically
as part of the create user api call.
When using identity v3, the user gets no role on the project by
default, so a role must be added.

Member is the role available for that in devstack - I'm not convinced
it should be a default in tempest though.
We tried moving away from devstack specific configuration defaults in tempest.

andrea

>
>
> The heat_stack_owner role used to be created in juno devstack but no longer.
> Is there a reason to leave this as the default?
>
> IIRC, the use of explicit role was removed in kilo (and maybe backported
> into
> juno?) and was replaced with the use of delegations. It removed the need for
> an explicit role to manipulate heat stacks. The config option is necessary
> because of branchless tempest considerations and that you might need a
> specific
> role to perform stack operations. [4][5] The use of _member_ on master is to
> indicate that the no special role is needed to perform stack operations.
> When
> icehouse support goes eol we probably can remove this option from tempest.
>
> -Matt Treinish
>
> [1]
> http://specs.openstack.org/openstack/qa-specs/specs/test-accounts-continued.html
> [2]
> http://git.openstack.org/cgit/openstack/tempest/commit/?id=8f26829e939a695732cd5a242dddf63a9a84ecb8
> [3]
> http://git.openstack.org/cgit/openstack-dev/devstack/commit/?id=72f026b60d350ede39e22e08b8f7f286fd0d2633
> [4]
> http://git.openstack.org/cgit/openstack/tempest/commit/?id=db9721dfecd99421f89ca9e263a97271e5f79ca0
> [5]
> http://git.openstack.org/cgit/openstack-dev/devstack/commit/?id=886cbb2a86e475a7982df1d98ea8452d0f9873fd
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>