I think it a good solution, I already put +1 :)
And, as to the scenario testcases, shall we:
1) remove test steps/checks already coverd in API test
2) remove sequence test cases (such as test_server_sequence_suspend_resume),
othersize scenario will get fatter and fatter
Original Mail
Sender: ＜ghanshyamm...@gmail.com＞
To: ＜openstack-dev@lists.openstack.org＞
Date: 2017/03/01 11:03
Subject: Re: [openstack-dev] [QA]Refactoring Scenarios manager.py
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
