Open Stack

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 <ken1ohmichi at 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.frittoli at 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-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/20170301/aad51b28/attachment-0001.html>