Hi Ajaya,
Thanks for offer to help :) Are you talking about tempest tests or in-tree keystone tests? Verifying custom roles can be challenging via API only driven tests such as tempest – as it requires to have the policies configured accordingly in the cloud under test (i.e. devstack). It should be possible to prepare support for custom roles in the policy at deployment time. If tempest what you’re aiming at, it would be good if you could file a bp to describe what kind of use cases you have in mind, and why you’d like to run them in tempest. As these would be keystone only tests, I wonder if they would be more fitting as unit / functional tests in the keystone tree? This approach would give you more flexibility in changing the policies. If you are interested in contributing to tempest tests in the keystone area, below are some ideas. A few bp which are related to tempest and keystone identity API v3: - Refactor tempest so that it may run consuming identity v3 only (or greater, when available) [1] - Setup dsvm tests which rely on identity v3 only (including intra-service communication) [2] - Cross domain testing: write tests to verify the impact of the domain scope on keystone itself and on the services [3] - Tempest without admin account (David Kranz’s blueprint): run tempest tests without the need of an “admin” account [4] Your very welcome to contribute to any of those. [3] and [4] are still in the design phase. The non-admin blueprint is loosely related to custom roles: it raised the question of how to run as many tests as possible without the need of an identity-admin account, which in certain deployments may be not available to the person running the tests. The concept of domain introduced in identity v3 may be helpful here, as a domain admin could be able to have full control within the boundaries of the domain. That can be true for keystone, as long as roles is defined and the policy in keystone is configured correctly. For services I believe there is no combination of custom roles / service policies that will allow to achieve this – to make an example use case, allow the domain admin to list all the VMs, images, containers and networks defined within projects that belong to the domain. I believe that for this to be possible we’ll have to wait for the hierarchical multi-tenancy in every projects. [5] Andrea p.s. Please use the openstack-dev list, openstack-qa is only used for reporting of periodic job test results. [1] https://github.com/openstack/qa-specs/blob/master/specs/multi-keystone-api-version-tests.rst [2] https://github.com/openstack/qa-specs/blob/master/specs/keystone-v3-jobs.rst [3] http://docs-draft.openstack.org/98/83898/5/check/gate-qa-specs-docs/4372c5f/doc/build/html/specs/cross-domain-testing.html [4] http://docs-draft.openstack.org/67/86967/6/check/gate-qa-specs-docs/d0c8170/doc/build/html/specs/run-without-admin.html [5] https://etherpad.openstack.org/p/juno-cross-project-hierarchical-multitenancy From: Ajaya Agrawal [mailto:ajku....@gmail.com] Sent: 03 June 2014 20:38 To: openstack-qa Subject: [openstack-qa] Tests for Custom roles in keystone v3 Hi, Is someone writing tests for custom roles and policies in keystone v3. for e.g. one could create a role called project_admin who would allowed to create/delete users in his project only. Andrea, Sean said in irc that you are working on this thing. Would you like to have one more pair of hands on this? :) Cheers, Ajaya
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
