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

Andrea Frittoli andrea.frittoli at gmail.com
Wed Mar 1 12:49:39 UTC 2017


On Wed, Mar 1, 2017 at 12:39 PM Jordan Pittier <jordan.pittier at scality.com>
wrote:

> On Wed, Mar 1, 2017 at 3:57 AM, Ghanshyam Mann <ghanshyammann at gmail.com>
> wrote:
>
> 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 ?
>

Yeah +1 on that - we need to refactor scenario to fix debuggability,
maintainability and ability to get contributions.
Moving helpers to lib is an option, but it's a lower priority in my view.


>
> 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
> https://docs.openstack.org/developer/tempest/plugin.html#stable-tempest-apis-plugins-may-use
> 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
> document.
> __________________________________________________________________________
> 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/985e5ef0/attachment.html>


More information about the OpenStack-dev mailing list