<div dir="ltr">Hi Andrea,<div><br></div><div>I am not sure why the new tempest.scenario.manager has to be developed that way. May I humbly suggest another path? Roughly goes like:</div><div><br></div><div>1) Rename the present class to "OldScenarioTest", set the original name to point to it (ScenarioTest=OldScenarioTest) (in a single commit)</div><div><br></div><div>2) Create a new class NewScenarioTest (initially a copy of the old one?), development/refactoring/rewrite happens there, do not merge any new features in OldScenarioTest</div><div><div><br class="gmail-Apple-interchange-newline">3) add a tempest config option "USE_NEW_SCENARIO_MANAGER", False by default</div></div><div><br></div><div>4) conditionally on the value of USE_NEW_SCENARIO_MANAGER set the ScenarioTest to point to OldScenarioTest or NewScenarioTest</div><div><br></div><div>5) add a gate job(s) to tempest that forces USE_NEW_SCENARIO_MANAGER to True to test the new code, non-voting from the start, gate on it later</div><div><br></div><div>This way the projects using tempest plugins and other tempest consumers will not be affected at all. Later each project on its jobs using tempest can try to enforce USE_NEW_SCENARIO_MANAGER to True if wishing to test the new one or switch to it when it is ready. Eventually when new one is stable, the config option might be removed and new class renamed to the name of the original class.</div><div><br></div><div>The only downside of such approach I see might be a small? explosion of number of jobs in the tempest project (running on both new and old manager), but I'd think at least in the beginning of this refactoring effort the tempest team would like to have the number of jobs testing the new manager limited any way.</div><div><br></div><div>I might be completely wrong with this advice, as I presume tempest team have put a lot of thinking into this problem already. But still, could you consider such approach?</div><div><br></div><div>Cheers,</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr">Dr. Pavlo Shchelokovskyy<div>Senior Software Engineer</div><div>Mirantis Inc</div><div><a href="http://www.mirantis.com" target="_blank">www.mirantis.com</a></div></div></div></div></div></div>
<br><div class="gmail_quote">On Mon, Feb 27, 2017 at 1:34 PM, Andrea Frittoli <span dir="ltr"><<a href="mailto:andrea.frittoli@gmail.com" target="_blank">andrea.frittoli@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hello folks,<div><br></div><div><div>TL;DR: if today you import manager,py from tempest.scenario please maintain a copy of [0] in tree until further notice.</div><div><br></div></div><div>Full message:</div><div>------------------</div><div><br></div><div>One of the priorities for the QA team in the Pike cycle is to refactor scenario tests to a sane code base [1].<br></div><div><br></div><div>As they are now, changes to scenario tests are difficult to develop and review, and failures in those tests are hard to debug, which is in many directions far away from where we need to be.<br></div><div><br></div><div>The issue we face is that, even though tempest.scenario.manager is not advertised as a stable interface in Tempest, many project use it today for convenience in writing their own tests. We don't know about dependencies outside of the OpenStack ecosystem, but we want to try to make this refactor a smooth experience for our uses in OpenStack, and avoid painful gate breakages as much as possible.</div><div><br></div><div>The process we're proposing is as follows:</div><div>- hold a copy of [0] in tree - in most cases you won't even have to change your imports as a lot of projects use tempest/scenario in their code base. You may decide to include the bare minimum you need from that module instead of all of it. It's a bit more work to make the patch, but less un-used code lying around afterwards.</div><div>- the QA team will refactor scenario tests, and make more interfaces stable (test.py, credential providers). We won't advertise every single change in this process, only when we start and once we're done.</div><div>- you may decide to discard your local copy of manager.py and consume Tempest stable interfaces directly. We will help with any question you may have on the process and on Tempest interfaces.</div><div><br></div><div>Repositories affected by the refactor are (based on [2]):</div><div><br></div><div>blazar,ceilometer,congress,<wbr>intel-nfv-ci-tests,ironic,<wbr>manila,networking-bgpvpn,<wbr>networking-fortinet,<wbr>networking-sfc,neutron-fwaas,<wbr>neutron-lbaas,nova-lxd,<wbr>octavia,sahara-tests,tap-as-a-<wbr>service,tempest-horizon,<wbr>vmware-nsx,watcher</div><div><br></div><div>If we don't hear from a team at all in the next two weeks, we will assume that the corresponding Tempest plugin / bunch of tests is not in use anymore, and ignore it. If you use <a href="http://tempest.scenario.manager.py" target="_blank">tempest.scenario.manager.py</a> today and your repo is not on the list, please let us know!</div><div><br></div><div>I'm happy to propose an initial patch for any team that may require it - just ping me on IRC (andreaf).</div><div>I won't have the bandwidth myself to babysit each patch through review and gate though.</div><div><br></div><div>Thank you for your cooperation and patience!</div><div><br></div><div>Andrea</div><div><br></div><div>[0] <a href="http://git.openstack.org/cgit/openstack/tempest/tree/tempest/scenario/manager.py" target="_blank">http://git.openstack.org/cgit/<wbr>openstack/tempest/tree/<wbr>tempest/scenario/manager.py</a> </div><div>[1] <a href="https://etherpad.openstack.org/p/pike-qa-priorities" target="_blank">https://etherpad.<wbr>openstack.org/p/pike-qa-<wbr>priorities</a></div><div>[2] <a href="https://github.com/andreafrittoli/tempest_stable_interfaces/blob/master/data/get_deps.sh" target="_blank">https://github.com/<wbr>andreafrittoli/tempest_stable_<wbr>interfaces/blob/master/data/<wbr>get_deps.sh</a> </div></div>
<br>______________________________<wbr>______________________________<wbr>______________<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.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br></blockquote></div><br></div>