<div dir="ltr">Hi Pavlo,<div><br></div><div>thank you for your suggestion.</div><div>See my comments inline.</div><div><br></div><div>andrea<br><div class="gmail_quote"><div dir="ltr">On Thu, Mar 2, 2017 at 9:19 AM Pavlo Shchelokovskyy <<a href="mailto:pshchelokovskyy@mirantis.com">pshchelokovskyy@mirantis.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg">Hi Andrea,<div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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 class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">1) Rename the present class to "OldScenarioTest", set the original name to point to it (ScenarioTest=OldScenarioTest) (in a single commit)</div></div></blockquote><div> </div><div>We considered a similar option [0], but I fear that maintaining the old class in Tempest, and even gating on it, would just postpone the issue for plugins, and would probably have the negative effect of making even more plugin rely on that.  </div><div>  </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_msg"></div><div class="gmail_msg">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 class="gmail_msg"><div class="gmail_msg"><br class="m_-4243893023369836055gmail-Apple-interchange-newline gmail_msg">3) add a tempest config option "USE_NEW_SCENARIO_MANAGER", False by default</div></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">4) conditionally on the value of USE_NEW_SCENARIO_MANAGER set the ScenarioTest to point to OldScenarioTest or NewScenarioTest</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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></blockquote><div><br></div><div>Having a gate job like this would make it really hard for us to get rid of the it in future. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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 class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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 class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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 class="gmail_msg"><br class="gmail_msg"></div></div></blockquote><div><br></div><div>Another option would be to:</div><div>- create a new base class in Tempest</div><div>- incrementally move scenario tests across to the new base class, along with the helpers they need</div><div>However this would have the drawback of risking to break plugins again and again, and to slow down the overall process.<br></div><div><br></div><div><br></div><div>[0] <a href="https://review.openstack.org/#/c/439291/1">https://review.openstack.org/#/c/439291/1</a> </div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_msg"></div><div class="gmail_msg">Cheers,</div></div><div class="gmail_extra gmail_msg"><br clear="all" class="gmail_msg"><div class="gmail_msg"><div class="m_-4243893023369836055gmail_signature gmail_msg" data-smartmail="gmail_signature"><div dir="ltr" class="gmail_msg"><div class="gmail_msg"><div dir="ltr" class="gmail_msg">Dr. Pavlo Shchelokovskyy<div class="gmail_msg">Senior Software Engineer</div><div class="gmail_msg">Mirantis Inc</div><div class="gmail_msg"><a href="http://www.mirantis.com" class="gmail_msg" target="_blank">www.mirantis.com</a></div></div></div></div></div></div>
<br class="gmail_msg"><div class="gmail_quote gmail_msg"></div></div><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg">On Mon, Feb 27, 2017 at 1:34 PM, Andrea Frittoli <span dir="ltr" class="gmail_msg"><<a href="mailto:andrea.frittoli@gmail.com" class="gmail_msg" target="_blank">andrea.frittoli@gmail.com</a>></span> wrote:<br class="gmail_msg"></div></div><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg">Hello folks,<div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><div class="gmail_msg">TL;DR: if today you import manager,py from tempest.scenario please maintain a copy of [0] in tree until further notice.</div><div class="gmail_msg"><br class="gmail_msg"></div></div><div class="gmail_msg">Full message:</div><div class="gmail_msg">------------------</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">One of the priorities for the QA team in the Pike cycle is to refactor scenario tests to a sane code base [1].<br class="gmail_msg"></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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 class="gmail_msg"></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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 class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">The process we're proposing is as follows:</div><div class="gmail_msg">- 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 class="gmail_msg">- 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 class="gmail_msg">- 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 class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Repositories affected by the refactor are (based on [2]):</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">blazar,ceilometer,congress,intel-nfv-ci-tests,ironic,manila,networking-bgpvpn,networking-fortinet,networking-sfc,neutron-fwaas,neutron-lbaas,nova-lxd,octavia,sahara-tests,tap-as-a-service,tempest-horizon,vmware-nsx,watcher</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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" class="gmail_msg" target="_blank">tempest.scenario.manager.py</a> today and your repo is not on the list, please let us know!</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">I'm happy to propose an initial patch for any team that may require it - just ping me on IRC (andreaf).</div><div class="gmail_msg">I won't have the bandwidth myself to babysit each patch through review and gate though.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Thank you for your cooperation and patience!</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Andrea</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">[0] <a href="http://git.openstack.org/cgit/openstack/tempest/tree/tempest/scenario/manager.py" class="gmail_msg" target="_blank">http://git.openstack.org/cgit/openstack/tempest/tree/tempest/scenario/manager.py</a> </div><div class="gmail_msg">[1] <a href="https://etherpad.openstack.org/p/pike-qa-priorities" class="gmail_msg" target="_blank">https://etherpad.openstack.org/p/pike-qa-priorities</a></div><div class="gmail_msg">[2] <a href="https://github.com/andreafrittoli/tempest_stable_interfaces/blob/master/data/get_deps.sh" class="gmail_msg" target="_blank">https://github.com/andreafrittoli/tempest_stable_interfaces/blob/master/data/get_deps.sh</a> </div></div>
<br class="gmail_msg"></blockquote></div></div><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">__________________________________________________________________________<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">
<br class="gmail_msg"></blockquote></div></div>
__________________________________________________________________________<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></div>