Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. Honolulu
    1. Troubleshooting campaign status: INT-1883 - Reccurent various errors in smoke tests In Progress
      1. good progress on Master, still lots of patches in gate
      2. on daily Master still regular timeouts on basic_vm|cnf|network
        1. these 2E2 basic tests are leveraging A lacarte bpmn, it seems that most of the Service Providers priviledge the macro bpmn
        2. pnf_macro under integration in CI
        3. it would make sense to keep 1 test with a la carte workflow (basic_network) and move basic_vm and basic_cnf in macro Michal Jagiello and Morgan Richomme started working on this task
      3. Daily Guilin very stable - no so many timeouts for the basic_tests...so for sure the change of DB had an impact..we are not very good in evaluating the DB performance...important to address before B&R tests
      1. VID issue fixed
      2. Certificates at large fixed (openstack, AAI,..)
      1. Daily master of yesterday looks fine: https://logs.onap.org/onap-integration/daily/onap_daily_pod4_master/2021-03/23_11-52/
      2. Majority of the issues due to timeout on SO requests
        1. Issues could be due to SO or any other components SO is discussing with including DB
        2. On Guilin it is much more stable and for a full workflow it take usually 2 times less average (1100 versus 500s)
        3. Code did not changes that much => could be due to the DB upgrade
        4. #action morgan/michal: write basic_vm_macro, basic_cnf_macro
        5. Lukasz Rajewski indicates that we must keep the test of a la carte bpmn because they are usefull to specify vnf order and complete macro mode
        6. the goal is not to exclude these tests but to create new one on macro mode which is the main used bpmn
        7. Krzysztof Kuzmicki indicates that some SO slow down are also affecting the pf-registrate, wich is using te macro mode
    2. Automated tests
      1. update on CDS regression test (session with Jozsef Csongva Morgan Richomme
        1. session done last week, it was possible to launch the mock and start running the tests
        2. some issues due to the fact that the test code was not fully up to date regarding master version
        3. #action morgan contact Lasse Kaihlavirta and see if integration in CSIT will nto make more sense
      2. DCAEmod integrated in CI Krzysztof Kuzmicki
        1. integrated in CI
        2. false negative (icon red but test green) due to the fact that the test was not declared in the test DB. Test added, so at teh end of xtesting the status is pushed ot the DB http://testresults.opnfv.org/onap/api/v1/results?case_name=dcaemod
        3. From a dashboard perspective => test in healthcheck = 1 project / Smoke = test involved several projects BUT test still executed as part of smoke test in CI (avoid race condition with DCAE healthcheck)
      3. tern integration in CI failed in last weekly (gitlab-ci under review)
        1. use of a bad env var for the weekly rules change merged to be retested
  2. Istambul
    1. Move Robot pod out of ONAP cluster (including robot)
      1. certificate and robot pod to be executed in onap-testing cluster
        1. deals only with xtesting (not the robot pod)
        2. the idea is to keep the onap namespace cleaned
        3. to be tested, only open question = cm shall be recreated in teh new onap-testing namespace? url seems OK in cm to allow x-namespace exchanges
    2.  PythonSDK
      1. which tests? what is poorly covered?
        1. vFWCL? scaleout?
        2. NBI
        3. basic loop (basic_clamp extended)
        4. ETSI bpmn?
        5. use cases?
    3. Robot
      1. Bell/apex (if not done in Honolulu)
    4. Add a retry capability in CI? other rules (if onap-helm or onap-k8s Fail "too much" => do not execute E2E tests to save CI time?)
      1. Open discussion on the missing tests
        1. Bartek Grzybowski Illia Halych  Backup & Restore
        2. Michał Jagiełło Krzysztof Kuzmicki Service Sanity check. Healthcheck are not enough, they may be PASS when the system is not working at all..Problem reported already (lots of Healthcheck tests do not provide more information that the onap-k8s checking that the pods are up&running). We have several examples when the pods are up&running but it does not wrok. Exception shall not caught to hide the issues. We would need to formalize a little bit to discuss with the PTL.
        3. Andreas Geissler we are missing a simple test checking the UI endpoint
          1. #action andreas morgan send a mail to PTL to collect admin and user UI and create a simple test checking that the UI are available
        4. user-98b79 add clair scan, even if it shall be done at LF, usually showing it in weekly is the fastest way for adoption
    5. CI dashboard: improved dashboard to identify regression over time (see xls graphs) - multi platforms?
  3. AoB

...