[openstack-dev] [QA][blazar][ceilometer][congress][intel-nfv-ci-tests][ironic][manila][networking-bgpvpn][networking-fortinet][networking-sfc][neutron][neutron-fwaas][neutron-lbaas][nova-lxd][octavia][sahara][tap-as-a-service][horizon][vmware-nsx][watcher][all] Refactor of Tempest scenario base classes
andrea.frittoli at gmail.com
Tue Mar 7 21:28:54 UTC 2017
an update on this.
It's about 10days since the original message, and the current status is:
- 3 patches merged, 1 approved (recheck)
- 5 patches submitted, pending approval
- 2 patches with a -1 (need more work)
- 7 patches submitted by me today (draft) - review needed
Thank you for your work on this!
I would recommend to prune the imported module as much as possible as well.
It would make it easier for the QA team to identify which interfaces on
Tempest side should be migrated to stable.
On Wed, Mar 1, 2017 at 1:25 PM Andrea Frittoli <andrea.frittoli at gmail.com>
> On Wed, Mar 1, 2017 at 2:21 AM Takashi Yamamoto <yamamoto at midokura.com>
> On Mon, Feb 27, 2017 at 8:34 PM, Andrea Frittoli
> <andrea.frittoli at gmail.com> wrote:
> > Hello folks,
> > TL;DR: if today you import manager,py from tempest.scenario please
> > a copy of  in tree until further notice.
> > Full message:
> > ------------------
> > One of the priorities for the QA team in the Pike cycle is to refactor
> > scenario tests to a sane code base .
> > As they are now, changes to scenario tests are difficult to develop and
> > review, and failures in those tests are hard to debug, which is in many
> > directions far away from where we need to be.
> > The issue we face is that, even though tempest.scenario.manager is not
> > advertised as a stable interface in Tempest, many project use it today
> > convenience in writing their own tests. We don't know about dependencies
> > outside of the OpenStack ecosystem, but we want to try to make this
> > a smooth experience for our uses in OpenStack, and avoid painful gate
> > breakages as much as possible.
> > The process we're proposing is as follows:
> > - hold a copy of  in tree - in most cases you won't even have to
> > your imports as a lot of projects use tempest/scenario in their code
> > You may decide to include the bare minimum you need from that module
> > of all of it. It's a bit more work to make the patch, but less un-used
> > lying around afterwards.
> i submitted patches for a few repos.
> i'd suggest to use the same gerrit topic for relevant patches.
> Thank you for looking into this!
> Having a common gerrit topic is a nice idea: "tempest-manager"
> I'm also tracking patches in this etherpad:
> > - the QA team will refactor scenario tests, and make more interfaces
> > (test.py, credential providers). We won't advertise every single change
> > this process, only when we start and once we're done.
> > - you may decide to discard your local copy of manager.py and consume
> > Tempest stable interfaces directly. We will help with any question you
> > have on the process and on Tempest interfaces.
> > Repositories affected by the refactor are (based on ):
> > If we don't hear from a team at all in the next two weeks, we will assume
> > that the corresponding Tempest plugin / bunch of tests is not in use
> > anymore, and ignore it. If you use tempest.scenario.manager.py today and
> > your repo is not on the list, please let us know!
> > I'm happy to propose an initial patch for any team that may require it -
> > just ping me on IRC (andreaf).
> > I won't have the bandwidth myself to babysit each patch through review
> > gate though.
> > Thank you for your cooperation and patience!
> > Andrea
> > 
> >  https://etherpad.openstack.org/p/pike-qa-priorities
> > 
> > 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
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev