Open Stack

We had a discussion about this at the qa meeting today around the 
following proposal:

tl;dr The test accounts feature provides the same functionality as the 
embedded credentials. We should deprecate the account information 
embedded directly in tempest.conf in favor of test-accounts, and remove 
those options at the beginning of the M cycle. We would also rework the 
non-isolated jobs to use parallel test accounts, with and without admin 
creds. Starting now, new features such as cleanup and tempest config 
will not be required to work well (or at all) if the embedded creds are 
used instead of test accounts.

We have (at least) three use cases that are important, and we want 
tempest to work well with all of them, but that means something 
different in each case:

1. throw-away clouds (ci, gate)
2. test clouds
3. production clouds

For (1), the most important thing is that failing tests not cause false 
negatives in other tests due to re-using a tenant. This makes tenant 
isolation continue to be a good choice here, and requiring admin is not 
an issue. In a perfect world where tempest never left behind any 
resources regardless of an error at any line of code, test accounts 
could be used. But we are probably a long way from that.

For (3), we cannot use admin creds for tempest runs, and test accounts 
with cleanup allow parallel execution, accepting the risk of a leak 
causing a false negative. The only way to avoid that risk is to stamp 
out all leak bugs in tempest.

For (2), either isolation or test accounts with cleanup can be used

The tempest.conf values are not used in any of these scenarios. Is there 
a reason they are needed for anything?

  -David