<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Fri, Jun 19, 2015 at 10:30 AM Matthew Treinish <<a href="mailto:mtreinish@kortar.org" target="_blank">mtreinish@kortar.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, Jun 18, 2015 at 02:13:56PM -0400, David Kranz wrote:<br>
> We had a discussion about this at the qa meeting today around the following<br>
> proposal:<br>
><br>
> tl;dr The test accounts feature provides the same functionality as the<br>
> embedded credentials. We should deprecate the account information embedded<br>
> directly in tempest.conf in favor of test-accounts, and remove those options<br>
> at the beginning of the M cycle. We would also rework the non-isolated jobs<br>
> to use parallel test accounts, with and without admin creds. </blockquote><div>+1<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Starting now,<br>
> new features such as cleanup and tempest config will not be required to work<br>
> well (or at all) if the embedded creds are used instead of test accounts.<br>
<br>
So this was always the long term plan when we started work on the test-accounts<br>
mechanism about a year ago. We were holding off on deprecating the original<br>
config option based approach until finished the role and network support for<br>
test accounts and we had jobs setup using the mechanism. Now that the we<br>
finished both role and network support all that's left is setting up the jobs.<br>
I don't think there would be any opposition to marking the user and alt user<br>
options as deprecated after that. Also leaving in line comments (and maybe emit<br>
a warning) marking the non-locking provider mechanism as going away, probably<br>
in M. That way we start clearly marking to users that these options will be<br>
going away.<br></blockquote><div>+1 because the options are completely moving out of conf, we cannot use the deprecation mechanism from oslo.config - emitting a warning is a good idea </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
><br>
> We have (at least) three use cases that are important, and we want tempest<br>
> to work well with all of them, but that means something different in each<br>
> case:<br>
><br>
> 1. throw-away clouds (ci, gate)<br>
> 2. test clouds<br>
> 3. production clouds<br>
<br>
Well, tempest is designed to and tries to support running against any OpenStack<br>
cloud. I'm not sure if there are more deployment types than these 3 categories<br>
but we should also be supporting those too.<br>
<br>
><br>
> For (1), the most important thing is that failing tests not cause false<br>
> negatives in other tests due to re-using a tenant. This makes tenant<br>
> isolation continue to be a good choice here, and requiring admin is not an<br>
> issue. In a perfect world where tempest never left behind any resources<br>
> regardless of an error at any line of code, test accounts could be used. But<br>
> we are probably a long way from that.<br>
<br>
So the cleanup issue here is actually a wider openstack issue. Tempest will<br>
*always* call delete on created projects and users. This was a requirement for<br>
making test accounts work. (the mechanism for calling delete or freeing a<br>
credential set from the list is shared) With tenant isolation this means we'll<br>
be deleting a project and users and resources scoped to either may not be<br>
deleted first. (if there is a tempest or openstack bug) This is a wider issue<br>
for all OpenStack projects that there was a thread a few months ago discussing.<br>
<br>
><br>
> For (3), we cannot use admin creds for tempest runs, and test accounts with<br>
> cleanup allow parallel execution, accepting the risk of a leak causing a<br>
> false negative. The only way to avoid that risk is to stamp out all leak<br>
> bugs in tempest.<br>
<br>
Well depending on the resource in leak in question test accounts would likely<br>
catch the issues if there is a list on that resource in a later test. But, I<br>
agree, resource leaks have always been treated as bugs and we'll continue to<br>
do so.<br>
<br>
><br>
> For (2), either isolation or test accounts with cleanup can be used<br>
><br>
> The tempest.conf values are not used in any of these scenarios. Is there a<br>
> reason they are needed for anything?<br>
><br>
<br>
So the only thing that uses config options for credentials is actually tenant<br>
isolation, which uses them to provide admin credentials to do the dynamic<br>
creation of accounts. The real advantage of tenant isolation, besides not<br>
reusing anything, is actually its configuration simplicity. Using an accounts<br>
file can be tricky to use, there are a lot of little gotchas and assumptions<br>
in how you write the file. (which we try to document in both the config guide<br>
and the sample accounts.yaml file) It also requires a large number of users to<br>
be provided depending on the concurrency you're running with. While tenant<br>
isolation requires just setting 3-5 config options and you're fine after that.<br>
<br>
I don't think requiring the use of an accounts file for tenant isolation makes<br>
much sense, it's really heavyweight for 1 set of admin creds. Which probably<br>
means we should keep the admin user config option around. Although it might make<br>
more sense to move those options to the auth section. (and maybe rename them to<br>
make it clear that it's for tenant isolation only)<br>
<br></blockquote><div>I would also keep the admin account in tempest.conf. </div><div>And +1 to renaming the config options. </div><div>If tenant isolation is disabled, we will still need admin accounts for several tests - but those will have to be provided in the YAML file, otherwise we won't be able to support parallel run of admin tests. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
-Matt Treinish<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div></div>