<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Wed, Mar 1, 2017 at 12:54 PM Sean Dague <<a href="mailto:sean@dague.net">sean@dague.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 03/01/2017 07:35 AM, Jordan Pittier wrote:<br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
> On Wed, Mar 1, 2017 at 3:57 AM, Ghanshyam Mann <<a href="mailto:ghanshyammann@gmail.com" class="gmail_msg" target="_blank">ghanshyammann@gmail.com</a><br class="gmail_msg">
> <mailto:<a href="mailto:ghanshyammann@gmail.com" class="gmail_msg" target="_blank">ghanshyammann@gmail.com</a>>> wrote:<br class="gmail_msg">
><br class="gmail_msg">
>     Doing gradual refactoring and fixing plugins time to time needs lot<br class="gmail_msg">
>     of wait and sync.<br class="gmail_msg">
><br class="gmail_msg">
>     That needs:<br class="gmail_msg">
>     1. Plugins to switch from current method usage. Plugins to have some<br class="gmail_msg">
>     other function or same copy paste code what current scenario base<br class="gmail_msg">
>     class has.<br class="gmail_msg">
>     2. Tempest patch to wait for plugin fix.<br class="gmail_msg">
>     3. Plugins to switch back to stable interface once Tempest going to<br class="gmail_msg">
>     provide those.<br class="gmail_msg">
><br class="gmail_msg">
>     This needs lot of sync between tempest and plugins and we have to<br class="gmail_msg">
>     wait for tempest refactoring patch for long.<br class="gmail_msg">
><br class="gmail_msg">
>     To make it more efficient, how about this:<br class="gmail_msg">
>     1. Keep the scenario manger copy in tempest as it is. for plugins<br class="gmail_msg">
>     usage only.<br class="gmail_msg">
><br class="gmail_msg">
> Given that the refactoring effort "started" a year ago, at the current<br class="gmail_msg">
> speed it may take 2 years to complete. In the mean time we will have a<br class="gmail_msg">
> massive code duplication and a maintenance burden.<br class="gmail_msg">
><br class="gmail_msg">
>     2. Start refactoring the scenario framework by adding more and more<br class="gmail_msg">
>     helper function under /common or lib.<br class="gmail_msg">
><br class="gmail_msg">
> Starting a "framework" (each time I see that word, I have a bad feeling)<br class="gmail_msg">
> from scratch without users and usage is very very difficult. How do we<br class="gmail_msg">
> know what we need in that framework and what will be actually used in<br class="gmail_msg">
> tests ?<br class="gmail_msg">
<br class="gmail_msg">
I'm with Jordan, honestly, common functions and inheritance aren't going<br class="gmail_msg">
to help anyway. My feeling is that the only way to sanely take things<br class="gmail_msg">
forward is to start pivoting towards fixtures. And basically error if<br class="gmail_msg">
inheritance is used in tests. The functions on base classes is what is<br class="gmail_msg">
causing all the pain of rewind, because it's not a contract, but it's<br class="gmail_msg">
also magically there, so people try to use it.<br class="gmail_msg">
<br class="gmail_msg">
This would mean that every test would have more setUp with a bunch of<br class="gmail_msg">
explicit fixtures, but that's fine, it's a little more time thinking<br class="gmail_msg">
through the writing of the tests, and a lot easier to read them to know<br class="gmail_msg">
what is going on, and to delete them later. Basically get rid of all<br class="gmail_msg">
class/superclass magic.<br class="gmail_msg">
<br class="gmail_msg">
> The effort was called scenario refactoring and I think that's what we<br class="gmail_msg">
> should do. We should not do "start from scratch scenarios" or "copy all<br class="gmail_msg">
> the code and see what happens".<br class="gmail_msg">
><br class="gmail_msg">
> There's no problem with plugins. We committed to have a stable interface<br class="gmail_msg">
> which is documented and agreed upon. It's clearly written<br class="gmail_msg">
> here <a href="https://docs.openstack.org/developer/tempest/plugin.html#stable-tempest-apis-plugins-may-use" rel="noreferrer" class="gmail_msg" target="_blank">https://docs.openstack.org/developer/tempest/plugin.html#stable-tempest-apis-plugins-may-use</a><br class="gmail_msg">
> The rest is private, for Tempest internal use. If Tempest cores disagree<br class="gmail_msg">
> with that, then we should first of all put a spec and rewrite that<br class="gmail_msg">
> document.<br class="gmail_msg">
<br class="gmail_msg">
It does seem like there is a tough love moment coming about the fact<br class="gmail_msg">
that APIs were consumed that were specifically out of bounds. Either the<br class="gmail_msg">
team commits to them inbounds, and there is the contract, or moves<br class="gmail_msg">
forward under the existing contract.<br class="gmail_msg">
<br class="gmail_msg">
Though, I expect the issue is that because all the Tempest tests work in<br class="gmail_msg">
this super class way, this is the only stuff people understood and copy<br class="gmail_msg">
pasted. So it does feel like there has to be at least a couple of<br class="gmail_msg">
instances in the Tempest tree of how the team *wants* other projects to<br class="gmail_msg">
write tests that they can point people to.<br class="gmail_msg"></blockquote><div><br></div><div>+1 on this. Which is why we need to refactor our scenario test to a sane code<br></div><div>base that people can use as examples to copy paste.</div><div><br></div><div>The basic credentials provider services that comes with test.py is something</div><div>that is useful to have I think - and we are working on make them a contract people</div><div>can rely on. </div><div><br></div><div>We had a discussion at the PTG about how to deal with those, and the conclusion</div><div>was that we are going to move credentials providers to tempest.lib and keep </div><div>test.py more or less as it is and declare it a stable interface for plugins.</div><div><br></div><div>Alternatives like dropping class fixtures for good, and move everything to be test</div><div>fixtures, involve too much code churn / refactor for an advantage which </div><div>is too little - and we wouldn't have the bandwidth to do that anyways.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class="gmail_msg">
        -Sean<br class="gmail_msg">
<br class="gmail_msg">
--<br class="gmail_msg">
Sean Dague<br class="gmail_msg">
<a href="http://dague.net" rel="noreferrer" class="gmail_msg" target="_blank">http://dague.net</a><br class="gmail_msg">
<br class="gmail_msg">
__________________________________________________________________________<br class="gmail_msg">
OpenStack Development Mailing List (not for usage questions)<br class="gmail_msg">
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" class="gmail_msg" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br class="gmail_msg">
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" class="gmail_msg" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br class="gmail_msg">
</blockquote></div></div>