[openstack-dev] [tempest] BadAltAuth / Test Isolation same tenant
mtreinish at kortar.org
Mon Feb 8 20:01:39 UTC 2016
On Mon, Feb 08, 2016 at 06:04:15PM +0100, Vincent Gatignol wrote:
> Hi there,
> I know that it's not the default configuration for openstack nor tempest but I need to make a script that test user isolation _inside_ the same tenant.
> Some of our users are in the same tenant but they must not interfere with each others.
> We have modified the nova policy rules and we must test these policies (the default one is : "rule:admin_or_user").
As I explained on IRC a couple of weeks ago this is a really bad idea. It breaks
all users expectations with using your cloud. The OpenStack APIs scope most
resources to the tenant/project changing that is changing fundamental behavior
of your cloud. Just because you can hand configure this doesn't mean you should.
> We are using tempest as a base tool with pre-provisioned credentials (cannot use admin account for security reasons)
> First thought was "easy" : load tempest with pre-created users via account.yaml file, all in the same tenant, and launch 'tempest.api.compute.test_authorization' that contains almost what we need to test.
> But we ran into the "BadAltAuth" exception and I don't know how to get rid of it except breaking the tempest_lib (skipping/commenting this exception)
> This exception is thrown when the accounts used in tempest have the same auth url.
> I tried another approach, without alt_authentication :
> From a prompt, I'm launching a test that creates a test_server and export its ID, then wait until the timeout value (default to 500s)
> From another prompt, I launch the real test that get the server ID and try to delete it. But the same BadAltAuth thing happen...
> (I'm using an account file with 2 different users in the same tenant and with the locking mechanism, the logic is using both accounts for this group of tests)
> So I'm asking here if someone have a clue to help us ?
Also, as I explained previously tempest is not designed to do this. The use case
for dynamic credentials and pre_provisioned credentials is to provide
credential sets with separate projects/tenants and users. This is because the
auth model for OpenStack has most resources scoped to the tenant/project so it's
providing isolation for each of the test classes. Tempest is for testing
OpenStack clouds and the modifications you've made to your deployment's policy
file I'd argue goes far enough to not be that anymore.
If you're still set on doing this the only method available to you is to have an
admin user create the additional users for your new test.
> It could be some kind of rewrite of tempest_lib/auth regarding this BadAltAuth, throwing a warning instead of a critical exception.
> Thank you all for your time answering this,
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: not available
More information about the OpenStack-dev