Open Stack

On Mon, 27 Feb 2017, 12:32 a.m. Ghanshyam Mann, <ghanshyammann at 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.frittoli at gmail.com> wrote:
>
>
> On Sun, Feb 26, 2017 at 12:49 AM Masayuki Igawa <masayuki at 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.pittier at 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-request at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170227/78115ebf/attachment.html>