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

Jordan Pittier jordan.pittier at scality.com
Wed Mar 1 12:35:26 UTC 2017

On Wed, Mar 1, 2017 at 3:57 AM, Ghanshyam Mann <ghanshyammann at gmail.com>

> 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.
Given that the refactoring effort "started" a year ago, at the current
speed it may take 2 years to complete. In the mean time we will have a
massive code duplication and a maintenance burden.

> 2. Start refactoring the scenario framework by adding more and more helper
> function under /common or lib.
Starting a "framework" (each time I see that word, I have a bad feeling)
from scratch without users and usage is very very difficult. How do we know
what we need in that framework and what will be actually used in tests ?

The effort was called scenario refactoring and I think that's what we
should do. We should not do "start from scratch scenarios" or "copy all the
code and see what happens".

There's no problem with plugins. We committed to have a stable interface
which is documented and agreed upon. It's clearly written here
The rest is private, for Tempest internal use. If Tempest cores disagree
with that, then we should first of all put a spec and rewrite that
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170301/ffad9eed/attachment.html>

More information about the OpenStack-dev mailing list