You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »



The intent of the 72 hour stability test is not to exhaustively test all functions but to run a steady load against the system and look for issues like memory leaks that aren't found in the short duration install and functional testing during the development cycle.

This page will collect notes on the 72 hour stability test run for Frankfurt.

See El Alto Stability Run Notes for comparison to previous runs.


Summary of Results


WORK IN PROGRESS



Setup

The integration-longevity tenant in Intel/Windriver environment was used for the 72 hour tests.

The onap-ci job for  "Project windriver-longevity-release-manual" was used for the deployment with the OOM set to frankfurt and Integration branches set to master. Integraiton master was used so we could catch the latest updates to integration scripts and vnf heat templates.

The jenkins job needs a couple of updates for each release:

  1. Set the integration branch to 'origin/master'
  2. Modify the parameters to deploy.sh to specify "-i master" and "-o frankfurt" to get integration master an oom frankfurt clones onto the nfs server.

The path for robot logs on dockerdata-nfs  changed in Frankfurt so the /dev-robot/   becomes /dev/robot





Shakedown consists of creating some temporary tags for stability72hrvLB, stability72hrvVG,stability72hrVFWCL to make sure each sub test ran successfully (including cleanup) in the environment before the jenkins job started with the higher level testsuite tag stability72hr that covers all three test types.



  • No labels