<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)">Doing gradual refactoring and fixing plugins time to time needs lot of wait and sync.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)">That needs:</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)">1. Plugins to switch from current method usage. Plugins to have some other function or same copy paste code what current scenario base class has.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)">2. Tempest patch to wait for plugin fix.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)">3. Plugins to switch back to stable interface once Tempest going to provide those. <br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)">This needs lot of sync between tempest and plugins and we have to wait for tempest refactoring patch for long. </div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)">To make it more efficient, how about this:</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)">1. Keep the scenario manger copy in tempest as it is. for plugins usage only.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)">2. Start refactoring the scenario framework by adding more and more helper function under /common or lib.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)">3. Once we feel all needed by scenario tests are available as stable helper, then ask each plugins to switch to stable interface.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)">4. After all helpers are available, with deprecation period of 1 cycle remove the scenario base class. </div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)"><br></div><div class="gmail_extra"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)">​Other way can be have copy of scenario manager or used interfaces in each plugins (as mentioned by Andrea) but that needs changes in almost all plugins and slow down Tempest work.​</div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)">​Have a look in this patch- <a href="https://review.openstack.org/#/c/439291/">https://review.openstack.org/#/c/439291/</a> </div><br></div><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div>-gmann</div></div></div></div>
<br><div class="gmail_quote">On Tue, Feb 28, 2017 at 3:28 AM, Ken'ichi Ohmichi <span dir="ltr"><<a href="mailto:ken1ohmichi@gmail.com" target="_blank">ken1ohmichi@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I see Jordan's opinion here and I also faced this situation before.<br>
I proposed a hacking patch [1] to notify wrong usage of Tempest<br>
methods to projects and I saw some users of these methods didn't know<br>
the definition of stable interfaces of Tempest.<br>
We always face this issue on developments which change *internal*<br>
methods of Tempest.<br>
<br>
2017-02-26 10:13 GMT-08:00 Andrea Frittoli <<a href="mailto:andrea.frittoli@gmail.com">andrea.frittoli@gmail.com</a>>:<br>
><br>
> Scenario tests will go through a significant number of changes as part of<br>
> the refactor and if every change risks to break someone's gate job it won't<br>
> work.<br>
> I propose we proceed as follows:<br>
> - identify projects that import from tempest.scenario<br>
> - send a notification to the ML about the changes that are going to happen<br>
> - help the affected teams to identify a way decouple them from tempest<br>
> scenario code - most likely copy the relevant code in-tree<br>
> - meanwhile continue to work on patches for scenario tests but do not merge<br>
> them yet<br>
<br>
Yeah, this approach is very nice to land patches softly.<br>
Users can find solutions if facing this issue on the own gate.<br>
<br>
> This process shouldn't take long and be rather straight forward.<br>
><br>
> I already have some data from codesearch, I will send out the e-mail<br>
> tomorrow.<br>
<br>
++, thanks for your leadership.<br>
<br>
Thanks<br>
Ken Ohmichi<br>
<br>
---<br>
<br>
[1]: <a href="https://review.openstack.org/#/c/328651" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/328651</a><br>
<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>
</blockquote></div><br></div></div>