Hi Infra group,
I got an action point this afternoon during the TSC meeting after the
presentation on the behalf of the testing working group on our vizion of
test evolution
(https://wiki.opnfv.org/download/attachments/9568526/testing%20evolution%20v1_3.pptx?version=2&modificationDate=1499788745000&api=v2)
We would like to run more stress/resiliency tests on "stable" releases.
This raises several questions:
* POD/resources
* capability to manage OPNFV releases
TSC would like to get a_concrete proposal it can vote on_ regarding this
topic.
We will discuss it tomorrow during the testing group meeting tomorrow
(APAC slot)
I imagine something like that (just a proposal), feel free to
comment/amend/modify
------------------------------------------------------------------------------------------------------------------------------------------------------------------
*Need*: be able to run stress/robustness/resiliency testing on OPNFV
People observed that unstability may occur on OPNFV releases after some
days or due to the repetition of basic tests.
Stress tests developed for Danube showed also that OPNFV solutions can
be crashed relatively easily...
These problems cannot be found when running systematically test suite
only once after on a fresh installation
Regarding current release pipeline, it is not possible to plan such
testing on OPNFV candidate release (stable solution ready for such tests
shortly before the release date)
*Benefit for the community*: Address EUAG pain point, contribute to
improve "Telco Grade" aspects, consolidate the confidence in the release
_*short term proposal (Danube/Euphrates transition)*_
once Danube 3.0 is over, use existing resources to reinstall an
os-nosdn-nofeature-ha scenario on
* lf-pod1 / apex
* huawei-pod2 / compass
* ericsson-pod1 / fuel
* intel-pod5 / joid
Use these pods for stress/robusteness tests until resources are
realocated for Euphrates: 14th of July to mid August ~ 1 month?
* main goal: run bottlenecks 2 scenarios developed for Danube
* optional (if time): planned slots for Storperf, VSPERF, qtip,
yardstick, functest
_Benefit:_
* get official feedback on the stress tests done for Danube (part of
Danube priorities) on what we really released
* almost no impact on resources (just stop re-installing + grant
access for troubleshooting on existing resources)
* Possibility to perform resiliency/stress on any "released" scenario
(even if it is theoretical as no test suites on K8s today)
_Drawback_
* if bug detected...bug will be reported to the installers but not
sure it could be fixed
* need lots of resources: PODs and people (at least 1 POD per installer)
_*mid term proposal (beyond Euphrates)*_
Allocate 1 pod for such activity based on OSA tagged version
* Intel-18 / OSA os-nosdn-nofeature-ha (tagged Pike)
The mid term solution will allow the testing community to work closed to
upstream independantly from the installers
detected bugs will be reported (and hopefully fixed) upstream
_Benefit:_
* bugs reported upstream
* 1 single source / no dependencies towards installers
* Need only 1 POD (Testing group shall self-organize the timeslot
allocation)
* Keep aligned on the target version (no real // testing, release
validation and stress tests done on the target release)
* Possibility to leverage test promotion
_Drawback:_
* Stress/resiliency test not directly related to
scenarios/installer..what we are releasing
* OpenStack centric
Note if you think mid term is achievable now (installation of an OSA
tagged Ocata on Intel-18) and people are fine with the approach we can
probably skip the short term
/Morgan
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
_______________________________________________
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
