<div class="zcontentRow"> <p>First I really appreciate Jordan's work, and I always appreciate those who really do something. If we don't have a begining, then we will never reach the end.</p><p><br></p><p>I now sort out the problem as:<br></p><p>1) Do we need to refactory the Tempest scenario code?  ------ yes</p><p>2) What if scenario refactory will affect many plugins which use scenario's unstable code?</p><p>    2.1) choice 1: plugins modify their code simply</p><p>           * for simplified modification, one week is enough</p><p>           * if plugins do nothing, then Tempest will not be responsible for their gate failures after one week.</p><p><br></p><p>    2.2) choice 2: scenario provides a set of "stable interfaces", and plugins switch to use them.</p><p>           * if many plugins use interfaces in scenario, then it may worth to have a stable base of scenario(not the current manager.py)</p><p>           * it will need more work in Tempest, but plugins will benefit from it.</p><p><br></p><p>to sum up, Tempest should let plugins feel as comfortable as we can, but if plugins doing nothing no matter what we do,</p><p>then they won't stop the pace of our scenario refactoring.</p><p><br></p><p>Zhufl      </p><p><br></p><div class="zMailSign"><div><div></div></div></div><div class="zMailFrom"></div><div><div class="zhistoryRow" style="display:block"><div class="zhistoryDes" style="width: 100%; height: 28px; line-height: 28px; background-color: #E0E5E9; color: #1388FF; text-align: center;" language-data="HistoryOrgTxt">Original Mail</div><div id="zwriteHistoryContainer"><div class="control-group zhistoryPanel"><div class="zhistoryHeader" style="padding: 8px; background-color: #F5F6F8;"><div><strong language-data="HistorySenderTxt">Sender: </strong><span class="zreadUserName"> <ghanshyammann@gmail.com>;</span></div><div><strong language-data="HistoryTOTxt">To: </strong><span class="zreadUserName" style="display: inline-block;"> <openstack-dev@lists.openstack.org>;</span></div><div><strong language-data="HistoryDateTxt">Date: </strong><span class="">2017/02/27 08:32</span></div><div><strong language-data="HistorySubjectTxt">Subject: </strong><span class="zreadTitle"><strong>Re: [openstack-dev] [QA]Refactoring Scenarios manager.py</strong></span></div></div><p class="zhistoryContent"><br></p><div><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)">Yea, there is no doubt we should refactor scenario tests but even those are internal interface it breaks plugins. We can argue that plugins should not be using those but before that tempest should have all required interface/class/helper as stable interface for plugins. which is what scenario tests refactoring is trying to do.  </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)"><div style="color:rgb(34,34,34);font-family:arial,sans-serif"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)">I agree with the process Andrea defined and we should follow the same.. If we can put a deadline for projects to fix, we can speed up our work of refactoring. I propose to keep refactoring patch for 2 week (including comments fixes etc) and give time to plugins to fix and yes we will help them.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)">After 2 week of time, we do not guarantee about any plugin failure (with very rare exception if interface is being used very widely)<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)">Let's not break plugins (what we doing as max as possible) but we really need each plugins helps on those. QA team fix plugins since starting and we have submitted lot of patches for many plugins to fix them and many of them never got attention or reviewed. </div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)">For such cases (which falls under 2 week of deadlines), yes plugins needs to take full responsibility if any of the tempest interface break them.</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)">-gmann</div></div></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_quote">On Mon, Feb 27, 2017 at 3:13 AM, 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_quote"><div dir="ltr">On Sun, Feb 26, 2017 at 12:49 AM Masayuki Igawa <<a href="mailto:masayuki@igawa.me" target="_blank">masayuki@igawa.me</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail-m_-7692244295590378954gmail_msg">Hi,<br class="gmail-m_-7692244295590378954gmail_msg"><br class="gmail-m_-7692244295590378954gmail_msg">Thank you for bringing this up.<br class="gmail-m_-7692244295590378954gmail_msg"><br class="gmail-m_-7692244295590378954gmail_msg">Yeah, I understand your frustration. We already have the document about our stable interface[1]. It says <br class="gmail-m_-7692244295590378954gmail_msg">------<br class="gmail-m_-7692244295590378954gmail_msg">Stability<br class="gmail-m_-7692244295590378954gmail_msg">Any code that lives in tempest/lib will be treated as a stable interface. This means that any public interface under the tempest/lib directory is expected to be a stable interface suitable for public consumption. However, for any interfaces outside of tempest/lib in the tempest tree (unless otherwise noted) or any private interfaces the same stability guarantees don't apply.<br class="gmail-m_-7692244295590378954gmail_msg">------<br class="gmail-m_-7692244295590378954gmail_msg"><br class="gmail-m_-7692244295590378954gmail_msg">So we can change private interfaces basically. However, I also assume that this document is not well known(or people just ignore it, though, maybe). So I'd like to advertise this policy here, and discuss it (if the discussion is needed.)</div><div class="gmail-m_-7692244295590378954gmail_msg"><br class="gmail-m_-7692244295590378954gmail_msg">[1] <a href="https://docs.openstack.org/developer/tempest/library.html#stability" class="gmail-m_-7692244295590378954gmail_msg" target="_blank">https://docs.openstack.org/<wbr>developer/tempest/library.<wbr>html#stability</a></div><div class="gmail-m_-7692244295590378954gmail_msg"><br class="gmail-m_-7692244295590378954gmail_msg"><div class="gmail_quote gmail-m_-7692244295590378954gmail_msg"><div class="gmail-m_-7692244295590378954gmail_msg">On Sat, Feb 25, 2017 at 22:39 Jordan Pittier <<a href="mailto:jordan.pittier@scality.com" class="gmail-m_-7692244295590378954gmail_msg" target="_blank">jordan.pittier@scality.com</a>> wrote:<br class="gmail-m_-7692244295590378954gmail_msg"></div><blockquote class="gmail_quote gmail-m_-7692244295590378954gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail-m_-7692244295590378954gmail_msg">Hi guys,<div class="gmail-m_-7692244295590378954gmail_msg">So I have a problem with these 2 patches here [1] and here [2]. You basically are blocking any attempt of refactoring manager.py. Refactoring that file has been our number one priority for 2 cycles, and so far hardly no one stepped up really to do the work, except me with these 2 patches. Let me remind you that that file is a gigantic mess, an so are our network scenarios. </div><div class="gmail-m_-7692244295590378954gmail_msg"><br class="gmail-m_-7692244295590378954gmail_msg"></div><div class="gmail-m_-7692244295590378954gmail_msg">The manager.py file in the scenarios directory has no stable interface, and it was never "advertised" so. That some plugins decided to use some private methods (such as this _get_network_by_name) is unfortunate but that should not block us from moving.</div></div></blockquote></div></div></blockquote><div><br></div><div>I agree this should not block us from moving, and as you mentioned we definitely need to move and I appreciate the fact that you started the work!</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail-m_-7692244295590378954gmail_msg"><div class="gmail_quote gmail-m_-7692244295590378954gmail_msg"><blockquote class="gmail_quote gmail-m_-7692244295590378954gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail-m_-7692244295590378954gmail_msg"><div class="gmail-m_-7692244295590378954gmail_msg"><br class="gmail-m_-7692244295590378954gmail_msg"></div><div class="gmail-m_-7692244295590378954gmail_msg">So just to be clear, if we really want to refactor our scenarios (and we must in my opinion), things will break for projects that are importing Tempest and using it outside of its stable interface. I am not interested in being the good Samaritan for the whole OpenStack galaxy, I have enough with the 6 core projects and the Tempest stable interface. So guys, if you are and don't want to go forward with [1] and [2], be sure I'll never touch those scenarios again. I am not upset, but we have to make clear decisions, sometimes difficult.</div></div></blockquote></div></div></blockquote><div><br></div><div>We have no way to know exactly who's using unstable interfaces in Tempest, so it's likely someone will have to change their code as a consequence of the refactor.</div><div>But I think it's important that we are good citizens and advertise well what's going to change, even if it's about an interface which is not declared as stable.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail-m_-7692244295590378954gmail_msg"><div class="gmail_quote gmail-m_-7692244295590378954gmail_msg"><blockquote class="gmail_quote gmail-m_-7692244295590378954gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail-m_-7692244295590378954gmail_msg"><div class="gmail-m_-7692244295590378954gmail_msg"><br class="gmail-m_-7692244295590378954gmail_msg"></div><div class="gmail-m_-7692244295590378954gmail_msg">[1] : <a href="https://review.openstack.org/#/c/436555/" class="gmail-m_-7692244295590378954gmail_msg" target="_blank">https://review.openstack.<wbr>org/#/c/436555/</a></div><div class="gmail-m_-7692244295590378954gmail_msg">[2] : <a href="https://review.openstack.org/#/c/438097/" class="gmail-m_-7692244295590378954gmail_msg" target="_blank">https://review.openstack.org/#<wbr>/c/438097/</a> </div></div>______________________________<wbr>______________________________<wbr>______________<br class="gmail-m_-7692244295590378954gmail_msg"> OpenStack Development Mailing List (not for usage questions)<br class="gmail-m_-7692244295590378954gmail_msg"> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" class="gmail-m_-7692244295590378954gmail_msg" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br class="gmail-m_-7692244295590378954gmail_msg"> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" class="gmail-m_-7692244295590378954gmail_msg" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br class="gmail-m_-7692244295590378954gmail_msg"> </blockquote></div></div><div dir="ltr" class="gmail-m_-7692244295590378954gmail_msg">-- <br class="gmail-m_-7692244295590378954gmail_msg"></div><div class="gmail-m_-7692244295590378954gmail_msg"><div dir="ltr" class="gmail-m_-7692244295590378954gmail_msg">Masayuki Igawa</div></div>______________________________<wbr>______________________________<wbr>______________<br class="gmail-m_-7692244295590378954gmail_msg"> OpenStack Development Mailing List (not for usage questions)<br class="gmail-m_-7692244295590378954gmail_msg"> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" class="gmail-m_-7692244295590378954gmail_msg" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br class="gmail-m_-7692244295590378954gmail_msg"> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" class="gmail-m_-7692244295590378954gmail_msg" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a></blockquote><div><br></div><div>Scenario tests will go through a significant number of changes as part of the refactor and if every change risks to break someone's gate job it won't work.<br></div><div>I propose we proceed as follows:</div><div>- identify projects that import from tempest.scenario </div><div>- send a notification to the ML about the changes that are going to happen</div><div>- help the affected teams to identify a way decouple them from tempest scenario code - most likely copy the relevant code in-tree</div><div>- meanwhile continue to work on patches for scenario tests but do not merge them yet<span style="color:rgb(0,0,0);font-family:arial,helvetica,sans-serif"></span></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br></div><div>This process shouldn't take long and be rather straight forward.</div><div><br></div><div>I already have some data from codesearch, I will send out the e-mail tomorrow.</div><span class="gmail-HOEnZb"><span style="color:#888888"><div><br></div><div>Andrea</div></span></span></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></div></div><p><br></p></div></div></div></div><p><br></p> </div>