Manager object should allow username, password, tenant to be passed in parameters

Fix proposed to branch: master
Review: https://review.openstack.org/6227

https://review.openstack.org/6227

Hi Rohit! :)

Could you detail precisely which test cases (or tests within test cases) need:

* Administrators privs to run
* Both an admin AND a non-admin user

I'd like to document this and move tests around so that it is clear exactly when we are expecting admin vs. non-admin users to be executing the test cases -- or if we want to run test cases with different sets of credentials (admin vs. non-admin) and validate different results where appropriate....

I'd actually prefer to keep the [compute-admin] section in the tempest conf and create a new tempest.config.ComputeAdminConfig class that stores information about the administrative user credentials needed to execute test cases that are specifically intended for admin users and eventually move these tests into a /tempest/tests/compute/admin/ directory...

Thoughts?
-jay

Hi Jay,

I need to add tests for create and delete flavors, specifically. This is one use case that I have come across.

* Create and delete flavor api can only be run by a user with an "admin" role. A user with Member role is unauthorized as per policy.json for flavorsmanage.

Currently, the default behavior is to run tests as non-admin users (list flavors, get flavor details etc). which is fine.

* To test create delete, i'd also need to call list. So either I run the whole suite as admin or just the create and delete API as
admin user.

Please suggest.

I do agree with your suggestions to separate the admin tests into another directory.

I think the real question is which tests *should* there be that need admin privs. Looking at the nova source I think that the following actions require admin:

pause
unpause
suspend
resume
migrate
reset_network
inject_network_info
lock
unlock
create_backup
migrate_live

But I am able to do a pause without being am admin user. Is this a bug in nova?
It is unfortunate that the admin APIs are not distinguished in a better way. What are the admin APIs and where are they documented?

@Rohit: I think having a separate /tempest/tests/compute/admin/test_flavors.py that contains all tests that are relevant for an admin (CRUD + list) and having /tempest/tests/compute/test_flavors.py contain tests that are relevant for a non-admin user (list only?) is the most appropriate solution.

@David: Yes, I agree it's not ideal (the documentation), but hopefully we can go through each API piece and identify those specs that are intended for admin only and move them into /tempest/tests/compute/admin/* with the ComputeAdminConfig object handling that configuration?

Jay, I agree. I was confused about pause working but that is expected because pause and some others actually have a policy of "admin or owner". So we have to be careful about these admin tests.

In case of flavor_create and flavor_delete, they are extensions (FlavorManage) __and__ need to be run as admin user.
So I can see two ways to segregate such tests.

1. /tempest/tests/compute/admin/test_flavors.py (as Jay suggested above)
2. /tempest/tests/compute/extensions/admin/test_flavor_extension.py
(and maybe have a ..extensions/nonadmin/ directory)

Since flavorsmanage.py resides in compute/contrib in nova source, I think structure (2) above
might be more closer to the source code.

Regardless of implementation, these the scenarios I need to be able to perform:

-As a normal user, run all tests that don't require admin access and verify they pass
-As a normal user, run all tests that do require admin access to verify they fail
-As an admin user, run all tests that require admin access and verify they pass
-As an admin user, run all tests using a normal user's tenant id and verify they pass
-As a normal user, run all tests around admin functionality and verify they fail

This is just the high level of the flexibility I'm looking for.

Another wrinkle is that I filed a bug about the fact that nova-client did identify the "admin apis" in its help.
https://bugs.launchpad.net/bugs/973708 I got this response:

   I don't think this is a bug, because:
   1. nova client just acts as an API caller, which does not know policy.json at all.
   2. policy.json is just one of implementations. For example, We can implementation policy with SQL backend.
   3. policy is dynamic. Operators can define their own rules in policy.

If (3) is really true then I don't understand how we can have tests that do what Daryl says above. This is really saying that whether or not a Compute API requires admin access is not part of the definition of the API. That doesn't make a lot of sense to me and seems not very helpful to users. I thought this modular implementation for extensions was so that you could add and control extensions without having to install a new release.

Fix proposed to branch: master
Review: https://review.openstack.org/6333

Reviewed: https://review.openstack.org/6333
Committed: http://github.com/openstack/tempest/commit/ff10d5577df75b50ddf5ae0fead837292c4b3209
Submitter: Jenkins
Branch: master

commit ff10d5577df75b50ddf5ae0fead837292c4b3209
Author: Jay Pipes <email address hidden>
Date: Fri Apr 6 14:18:50 2012 -0400

    Fixes LP 973338 - Add custom alt and admin manager

    * Adds new AltManager, AdminManager derived manager classes
    * Allows Manager to be inited with custom credentials
    * Adds config.ComputeAdminConfig class and setup
    * Updates test_authorization to use AltManager class

    Change-Id: Iff5b20fbdfb8979a775f30f7e07d6e06b29e6c1c