Versions Compared

Key

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

...

  1. Honolulu
    1. status:board review https://jira.onap.org/secure/RapidBoard.jspa?rapidView=229&selectedIssue=INT-1842
      1. action #all review your Jira ticket move to instanbul or close
    2. Daily Honolulu CI/CD chain created
      1. https://logs.onap.org/onap-integration/daily/onap_daily_pod4_honolulu/2021-04/
    3. Remaining work on tests
      1. basic_clamp: integrated in CI, several successful runs, but improvements needed to manage exceptions (Policy/DCAE/CLamp) => https://gerrit.onap.org/r/c/testsuite/pythonsdk-tests/+/120234

      2. basic_vm_macro (replace vfw_macro): in progress still some issues on the daily honolulu

      3. pnf_macro => add mechanism to have a better control of the pnf simu launch (timer is not enough) => # action Michal

      4. refactoring of 5gbulkpm => #action Krzysztof => test done this afternoon => merged

      5. tern: test declared in CI, but issue => # action morgan & Alexander

      6. stability tests

        1. I started the first resiliency tests: TEST-308 - [Resiliency] Evaluate ONAP behavior on k8s worker node restart

          1. Other labs are experiencing different issues
            1. Nokia => pod remain in stuck
            2. #action Daniel, Andreas create a JIRA ticket for each resiliency test
            3. #action morgan create a wiki page to consolidate resiliencey tests
        2. stability I planned to regive a try to Natacha's suite as soon as the other tests are OK

          1. to be tried asap: if enough resources => weekly Honolulu to be launched on Wednesday
      7. consolidation of versions: I was waiting for the come back of Pawel but as far as I understood, you will move to othe r challenges soon.. :) so I need to review that

        1. better exception catching

        2. integration of the GUI part to generate an html reporting (for the moment I usually replay manually the tests, get the results and apply the GUI processing manually)

      8. removal of the submodule: test in progress (seems there was an import in the simu step), once done we could review our docker build (to remove the developer mode) but we shall not forget to adapt xtesting-onap according ly (/Src/onaptests/src/onaptests => /usr/lib/python3.8/sites-available/onaptests

        1. #action morgan review the patch dealing with sumbmodule removal +  cherry + adapt xtesting-onap
      9. CDS / CSIT => will not have the resource to do it for Honolulu => move to Istanbul

      10. GUI tests: wait for completion of the Wiki page and see if enough bandwidth => move to instanbul

    4. documentation update started
    5. honolulu branching done
    6. release testsuite 1.8.0 to be done
  2. Istanbul
    1. requests from new project (OOF, AAI) "on how to bring new tests to integration" => How to help projects to integrate their tests in Integration?
      1. run robot tests out of onap namespace: How to run the tests out of the ONAP cluster?
      AoB
        1. Discussion on the support for AAI gatling tests. By default the multitenancy support is disabled and they require a keycloak third party
        2. first issue is the test env => we coudl imagine to have a daily scenario daily_master_multitenancy but we need to take care of the resources. Until we cannot rely on the windriver lab, it will be hard to create new scenarios...
        3. installation of keycloak shall be done in a tooling namespace through a helm chart => OOM
        4. Mohammad Hosnidokht indicated that gatling part is almost automated (docker verifying the roles)
        5. William Reehil indicated that it will probably break the other tests
        6. it is probably more relevant to start by creating a CSIT test (fonctional test) with AAI + keycloak rather than a daily.. 
        7. #action Morgan Richomme complete wiki instanbul page to track this scenario
      1. run robot tests out of onap namespace: How to run the tests out of the ONAP cluster?
    2. AoB
    •  Michał Jagiełło pnf_macro add processing for pnf_macro to wait for a clean startup of the simulator (currently time based, and it seems that it takes more time than expected)
    •  Michał Jagiełło complete basic_vm_macro
    •  all review the wiki page and add the links of the GUI you are using
    •  all review/complete the wiki on process to integrate new external tests in CSIT or CI
    •  Krzysztof Kuzmicki complete the official simulator page with NS illustration
    •  Illia Halych review the official simu page (pythonsdk wrapper)
    •  all review your Jira ticket move to instanbul or close
    •  Morgan Richomme review the patch dealing with sumbmodule removal +  cherry + adapt xtesting-onap
    •  Morgan Richomme complete wiki instanbul page to track this scenario

    1. Action point follow-up
      1. Morgan Richomme action morgan initiate Illia Halych committer promotion procedure
        1. done
      2. Morgan RichommeMichał Jagiełło develop basic_vm_macro and basic_cbf_macro
        1. basic_vm ready to be tested, basic_cnf shall be very closed
      3. Morgan Richommecontact Lasse Kaihlavirta to see if CDS regression could be integrated in CSIT
        1. done, no bandwidth available, Jira created
      4. Morgan RichommeAndreas Geisslerlist UI and create a healthcheck test to check the availability of the UI
        1. done, see next section
    2. Admin
      1. Committer promotion: formal vote initiated Committer Promotion Request for Integration Illia Halych
        1. vote in progress, please committer vote before the end of the week
      2. testing docker discussion (formating, unexpected removal of daily build dockers,..)
        1. 2 tickets created on LF
          1. "fresh" xtesting dockers disappear time to time on the nexus https://jira.linuxfoundation.org/plugins/servlet/theme/portal/2/IT-21812
          2. "impossible to release because the tag format of the snapshot docker does not respect some rules" => https://jira.linuxfoundation.org/plugins/servlet/theme/portal/2/IT-21710
          3. xtesting dockers are rebuilt daily based on the branches (guilin/master end of branches of all the components embedded in the docker), CI or end users cannot guess the format imposed by the LF rules (used for components e.g. 6.0-STAGING-20210315T185806Z)

    ...