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
__________________________________________________________________________
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
