[openstack-dev] [QA]Refactoring Scenarios manager.py

Masayuki Igawa masayuki at igawa.me
Sun Feb 26 00:46:12 UTC 2017


Thank you for bringing this up.

Yeah, I understand your frustration. We already have the document about our
stable interface[1]. It says
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>

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

More information about the OpenStack-dev mailing list