Doing gradual refactoring and fixing plugins time to time needs lot of wait and sync.
That needs: 1. Plugins to switch from current method usage. Plugins to have some other function or same copy paste code what current scenario base class has. 2. Tempest patch to wait for plugin fix. 3. Plugins to switch back to stable interface once Tempest going to provide those. This needs lot of sync between tempest and plugins and we have to wait for tempest refactoring patch for long. To make it more efficient, how about this: 1. Keep the scenario manger copy in tempest as it is. for plugins usage only. 2. Start refactoring the scenario framework by adding more and more helper function under /common or lib. 3. Once we feel all needed by scenario tests are available as stable helper, then ask each plugins to switch to stable interface. 4. After all helpers are available, with deprecation period of 1 cycle remove the scenario base class. Other way can be have copy of scenario manager or used interfaces in each plugins (as mentioned by Andrea) but that needs changes in almost all plugins and slow down Tempest work. Have a look in this patch- https://review.openstack.org/#/c/439291/ -gmann On Tue, Feb 28, 2017 at 3:28 AM, Ken'ichi Ohmichi <ken1ohmi...@gmail.com> wrote: > I see Jordan's opinion here and I also faced this situation before. > I proposed a hacking patch [1] to notify wrong usage of Tempest > methods to projects and I saw some users of these methods didn't know > the definition of stable interfaces of Tempest. > We always face this issue on developments which change *internal* > methods of Tempest. > > 2017-02-26 10:13 GMT-08:00 Andrea Frittoli <andrea.fritt...@gmail.com>: > > > > 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 > > Yeah, this approach is very nice to land patches softly. > Users can find solutions if facing this issue on the own gate. > > > 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. > > ++, thanks for your leadership. > > Thanks > Ken Ohmichi > > --- > > [1]: https://review.openstack.org/#/c/328651 > > __________________________________________________________________________ > 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
