On 6 April 2015 at 21:27, David Kranz <dkr...@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-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