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
