On Mon, 27 Feb 2017, 12:32 a.m. Ghanshyam Mann, <ghanshyamm...@gmail.com> wrote:
> 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. > > 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. > After 2 week of time, we do not guarantee about any plugin failure (with > very rare exception if interface is being used very widely) > I didn't want to an exact time frame in my message because I would say it depends on a case by case. > 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. > 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. > I don't think this will work if we do it on a patch by patch basis. It would slow us down too much and it would become an ongoing effort for other teams which is probably not sustainable. > -gmann > > On Mon, Feb 27, 2017 at 3:13 AM, Andrea Frittoli < > andrea.fritt...@gmail.com> wrote: > > > On Sun, Feb 26, 2017 at 12:49 AM Masayuki Igawa <masay...@igawa.me> wrote: > > Hi, > > Thank you for bringing this up. > > Yeah, I understand your frustration. We already have the document about > our stable interface[1]. It says > ------ > Stability > 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. > ------ > > 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.) > > [1] https://docs.openstack.org/developer/tempest/library.html#stability > > On Sat, Feb 25, 2017 at 22:39 Jordan Pittier <jordan.pitt...@scality.com> > wrote: > > Hi guys, > 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. > > 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. > > > 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! > > > > 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. > > > 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. > 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. > > > [1] : https://review.openstack.org/#/c/436555/ > [2] : https://review.openstack.org/#/c/438097/ > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- > Masayuki Igawa > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > 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. > I propose we proceed as follows: > - identify projects that import from tempest.scenario > - send a notification to the ML about the changes that are going to happen > - help the affected teams to identify a way decouple them from tempest > scenario code - most likely copy the relevant code in-tree > - meanwhile continue to work on patches for scenario tests but do not > merge them yet > > > This process shouldn't take long and be rather straight forward. > > I already have some data from codesearch, I will send out the e-mail > tomorrow. > > Andrea > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
