Open Stack

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170226/af934b9a/attachment.html>