This is a draft page to be discussed with Integration team to define priorities for Guilin
X-projects
- Maintain java11
- create python3.8 baseline image
Repositories
- Adopt the approach to create a repo for new use cases / simulators
- Add linters to all the new repositories
- Add new linters (robot, bashate, rst)
- How to get a consistent view on all the repositories, shall we tag all the repositories,..
- update xtesting repo and put in place the build chain in ONAP (move from gitlab.com to ONAP)
- update java/python3.8 in ONAP (move from gitlab.com to ONAP)
Robot pod
- Adopt micro-service approach introduced by Daniel (propto in F)
- move the helm chart back to OOM
Use case support
- Write an documentation 'Use case guideline"
- Test creation of an override.yaml per use case to be able to deploy adhoc environment in windriver
Tests
- update the tests
- harden the simulators/emulators (no more in xfail lists)
- clean? are all the tests still maintained?
- archive CIST? => projects can bring back their tests in their repository but jenkins CSIT not needed anymore
- move some of the CIST tests in Daily CI
- introduction of python_sdk for new tests (deprecate onap-tests)
- improve security tests (Integration and Built Tests For Releases)
- How to measure the test coverage?
- How to get better healthcheck tests and "force" project to update them when they provide a new version of their code
- Support OOM on a use case for Core on F→ G migration
Labs
- include endpoint supervizion page? (cachet?)
- Ops guideline (Zabbix/Prometheus/...) ?
CI/CD
- improve CI chains and CI testing gate
- new smoke use case
- vFW CL
- CDS
- ...
- integration of Portal GUI tests
- finalize windriver/gitlab.com pipelines
- introduce a weekly CI chain including robustness tests
| Caterogy | Task | nb people interested (add a "|" if you think it is valuable) | contacts | priority | Comment |
|---|---|---|---|---|---|
| X-project | maintain java11 | | | |||
| create python 3.8 baseline | || | ||||
| maintain oparent | | | ||||
| Repositories | Finalize generalization of linters | || | |||
| Create new repo (simu/use cases) | || | ||||
| reinsource build chain for java | || | medium | it is working very well in gitlan..but it is better to reinsource if we want to have contributors only allowed to contribute to ONAP. it is cleaner | ||
| reinsource xtesting build chain | || | low | same than for java | ||
| testsuite | adopt microservice approach | | | we missed it in Frankfurt to be done with the python3 final step + OOM chart back to helm | ||
| finalize python3 migration | | | ||||
| Move OOM chart back to helm | | | ||||
| use case | create a starting guide | || | can be based on the slide deck shared with use case people | ||
| create overide.yaml per use case / to dedicated automatic deployment | | | will depend if issue on windriver (slow access through python client) is fixed | |||
| tests | update/maintenance of existing tests | || | all | ||
| component coverage | good idea but how to do that... | ||||
| discussions with projects to improve healthcheck | | | status to be shared with PTLs + discussed with RM to set a milestone criteria? | |||
| update security tests - check versions of upstream components | || | ||||
| update security tests check java11/python3.8 | || | ||||
| update security tests - check certificates validity | | | there was a script somewhere..need to find it, create a test and integrate it in CI | |||
| update security tests - check limits | || | test already exists and in CI => not valid for daily (unlimited) but good in gating to be used for Guilin criteria | |||
| update existing security tests (review xfail list, cist,..) | ||| | the xfail lists of the different security tests will be reset for guilin | |||
| archive CIST? | | | current CSIT = functional tests => must be reinsourced by the project real CIST must be in CI | |||
| move CIST to E2E tests in CI | | | to be discussed with the projects maintaining their CIST tests | |||
| deprecate onap-tests / use python-onapsdk | || | ||||
| Support OOM for a migration | | | ||||
| stress tests | | | ||||
| long duration tests | | | ||||
| update integration web page | | | ||||
| Labs | supervision/monitoring | || | |||
| Create a ops guideline (with OOM?) | || | ||||
| infra gate (functest)? | | | ||||
| CI/CD | Integrate vFW Cl test | | | |||
| Integrate CDS tests | | | ||||
| Integrate GUI tests | | | ||||
| Create 5G xtesting dockers and integrate in CI? | | | ||||
| finalize windriver pipelines | | | ||||
| introduce a weekly pipleine (for long duration tests) | | |
2 Comments
Bartek Grzybowski
What is "tests"->"component coverage" topic exactly?
Bartek Grzybowski
Ok that was clarified on the integration bridge, thanks.
I asked this question because wasn't sure what type of components are we referring here and I understand those meant to be mainly core ONAP components if I got you right. For some time now I've been contributing tests and CI jobs for the components in integration repos that are not directly related to the core ONAP (i.e. some simulators) and wondered whether this task also belongs to what you meant by "components coverage" or should I maybe add some another entry in the table for those? One way or another I'm planning to provide further contributions for those.