Hi, Thanks. I just send patch [1] to add this new job to Neutron failure rate Grafana dashboard.
[1] https://review.openstack.org/#/c/583870/ > Wiadomość napisana przez Ghanshyam Mann <gm...@ghanshyammann.com> w dniu > 19.07.2018, o godz. 06:55: > >> On Sun, May 13, 2018 at 1:20 PM, Ghanshyam Mann <gm...@ghanshyammann.com> >> wrote: >>> On Fri, May 11, 2018 at 10:45 PM, Matt Riedemann <mriede...@gmail.com> >>> wrote: >>>> The tempest-full job used to run API and scenario tests concurrently, and >>>> if >>>> you go back far enough I think it also ran slow tests. >>>> >>>> Sometime in the last year or so, the full job was changed to run the >>>> scenario tests in serial and exclude the slow tests altogether. So the API >>>> tests run concurrently first, and then the scenario tests run in serial. >>>> During that change, some other tests were identified as 'slow' and marked >>>> as >>>> such, meaning they don't get run in the normal tempest-full job. >>>> >>>> There are some valuable scenario tests marked as slow, however, like the >>>> only encrypted volume testing we have in tempest is marked slow so it >>>> doesn't get run on every change for at least nova. >>> >>> Yes, basically slow tests were selected based on >>> https://ethercalc.openstack.org/nu56u2wrfb2b and there were frequent >>> gate failure for heavy tests mainly from ssh checks so we tried to >>> mark more tests as slow. >>> I agree that some of them are not really slow at least in today situation. >>> >>>> >>>> There is only one job that can be run against nova changes which runs the >>>> slow tests but it's in the experimental queue so people forget to run it. >>> >>> Tempest job >>> "legacy-tempest-dsvm-neutron-scenario-multinode-lvm-multibackend" >>> run those slow tests including migration and LVM multibackend tests. >>> This job runs on tempest check pipeline and experimental (as you >>> mentioned) on nova and cinder [3]. We marked this as n-v to check its >>> stability and now it is good to go as voting on tempest. >>> >>>> >>>> As a test, I've proposed a nova-slow job [1] which only runs the slow >>>> tests >>>> and only the compute API and scenario tests. Since there currently no >>>> compute API tests marked as slow, it's really just running slow scenario >>>> tests. Results show it runs 37 tests in about 37 minutes [2]. The overall >>>> job runtime was 1 hour and 9 minutes, which is on average less than the >>>> tempest-full job. The nova-slow job is also running scenarios that nova >>>> patches don't actually care about, like the neutron IPv6 scenario tests. >>>> >>>> My question is, should we make this a generic tempest-slow job which can >>>> be >>>> run either in the integrated-gate or at least in nova/neutron/cinder >>>> consistently (I'm not sure if there are slow tests for just keystone or >>>> glance)? I don't know if the other projects already have something like >>>> this >>>> that they gate on. If so, a nova-specific job for nova changes is fine for >>>> me. >>> >>> +1 on idea. As of now slow marked tests are from nova, cinder and >>> neutron scenario tests and 2 API swift tests only [4]. I agree that >>> making a generic job in tempest is better for maintainability. We can >>> use existing job for that with below modification- >>> - We can migrate >>> "legacy-tempest-dsvm-neutron-scenario-multinode-lvm-multibackend" job >>> zuulv3 in tempest repo >>> - We can see if we can move migration tests out of it and use >>> "nova-live-migration" job (in tempest check pipeline ) which is much >>> better in live migration env setup and controlled by nova. >>> - then it can be name something like >>> "tempest-scenario-multinode-lvm-multibackend". >>> - run this job in nova, cinder, neutron check pipeline instead of >>> experimental. >> >> Like this - >> https://review.openstack.org/#/q/status:open+project:openstack/tempest+branch:master+topic:scenario-tests-job >> >> >> That makes scenario job as generic with running all scenario tests >> including slow tests with concurrency 2. I made few cleanup and moved >> live migration tests out of it which is being run by >> 'nova-live-migration' job. Last patch making this job as voting on >> tempest side. >> >> If looks good, we can use this to run on project side pipeline as voting. > > Update on this thread: > Old Scenario job > "legacy-tempest-dsvm-neutron-scenario-multinode-lvm-multibackend" has been > migrated to Tempest as new job named "tempest-scenario-all" job[1] > > Changes from old job to new job: > - This new job will run all the scenario tests including slow with lvm > multibackend. Same as old job > - Executed the live migration API tests out of it. Live migration API tests > runs on separate nova job "nova-live-migration". > - This new job runs as voting on Tempest check and gate pipeline. > > This is ready to use for cross project also. i have pushed the patch to nova, > neutron, cinder to use this new job[3] and remove > "legacy-tempest-dsvm-neutron-scenario-multinode-lvm-multibackend" from > project-config[4]. > > Let me know your feedback on proposed patches. > > [1] http://git.openstack.org/cgit/openstack/tempest/tree/.zuul.yaml#n147 > [2] > https://review.openstack.org/#/q/topic:run-tempest-scenario-all-job+(status:open+OR+status:merged) > [3] > https://review.openstack.org/#/q/topic:run-tempest-scenario-all-job+(status:open+OR+status:merged) > [4] > https://review.openstack.org/#/q/topic:drop-legacy-scenario-job+(status:open+OR+status:merged) > >> >> -gmann >> >>> >>> Another update on slow tests is that we are trying the possibility of >>> taking back the slow tests in tempest-full with new job >>> "tempest-full-parallel" [5]. Currently this job is n-v and if >>> everything works fine in this new job then, we can make tempest-full >>> job to run the slow tests are it used to do previously. >>> >>>> >>>> [1] https://review.openstack.org/#/c/567697/ >>>> [2] >>>> http://logs.openstack.org/97/567697/1/check/nova-slow/bedfafb/job-output.txt.gz#_2018-05-10_23_46_47_588138 >>>> >>> >>> ..3 >>> http://codesearch.openstack.org/?q=legacy-tempest-dsvm-neutron-scenario-multinode-lvm-multibackend&i=nope&files=&repos= >>> >>> ..4 >>> https://github.com/openstack/tempest/search?utf8=%E2%9C%93&q=%22type%3D%27slow%27%22&type= >>> >>> ..5 >>> https://github.com/openstack/tempest/blob/9c628189e798f46de8c4b9484237f4d6dc6ade7e/.zuul.yaml#L48 >>> >>> >>> >>> -gmann >>> >>>> >>>> -- >>>> >>>> Thanks, >>>> >>>> Matt >>>> >>>> __________________________________________________________________________ >>>> 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 — Slawek Kaplonski Senior software engineer Red Hat __________________________________________________________________________ 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
