Skip to end of metadata
Go to start of metadata

This is a draft page to be discussed with Integration team to define priorities for Guilin


  • Maintain java11
  • create python3.8 baseline image


  • 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 to ONAP)
  • update java/python3.8 in ONAP (move from 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


  • 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


  • include endpoint supervizion page? (cachet?)
  • Ops guideline (Zabbix/Prometheus/...) ?


  • improve CI chains and CI testing gate
  • new smoke use case
    • vFW CL
    • CDS
    • ...
  • integration of Portal GUI tests
  • finalize windriver/ pipelines
  • introduce a weekly CI chain including robustness tests


nb people interested

(add a "|" if you think it is valuable)


maintain java11


create python 3.8 baseline||

maintain oparent|

RepositoriesFinalize generalization of linters||

Create new repo (simu/use cases)||

reinsource build chain for java||mediumit 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||lowsame than for java
testsuiteadopt 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 casecreate 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
testsupdate/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|


Create a ops guideline (with OOM?)||

infra gate (functest)?|

CI/CDIntegrate 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)|

  • No labels


  1. What is "tests"->"component coverage" topic exactly?

  2. 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.