Integration project is planning to setup an "Integration gate" to automate as many use cases as possible.
This gate has been initiated in El Alto through the daily and gating chains.
This patch is used to discuss the definition of the test categoris and the testcases to be associated.
1) infrastructure-healthcheck
goal: verify ONAP from a k8S perspective
| Use case | Type (driver) | Description | Comments |
|---|---|---|---|
| onap_k8s | python | list pods, deployments, events, cm, jobs check that the pods are up&running | already available (refactoring needed to be insourced - currently hosted on github) |
| onap_helm | python | list helm chart, check they are completed | already available (refactoring needed to be insourced - currently hosted on github) |
| ... |
2) healthcheck
goal: verify ONAP components
| Use case | Type (driver) | Description | Comments |
|---|---|---|---|
| core, small, medium, full | robot tags: core, small, medium,full | robot healthcheck tests with tag core/small/medium/full | already available (refactoring needed for the xtesting version to be insourced - currently hosted on github) |
| healthdist | robot tag: healthdist | onboarding/distribution of vFW model | already available (refactoring needed for the xtesting version to be insourced - currently hosted on github) |
| Post installation check | robot tag: postinstall | ||
This belongs to smoke-usecases. As said here, the sdc-dcae-d part of this should have been deprecated in Frankfurt (even though the related test cases are still there in CSIT and integration - I'll clarify with Ofir Sonsino ) but have several steps that are using core SDC, so the initial plan was to rewrite the test case without sdc-dcae-ds dependency |
3) smoke-usecases
goal: verify mature end to end use cases to validate the release
| Use case | Type (driver) | Description | Comments |
|---|---|---|---|
| vFWCL | robot tag: instantiateVFWCL | the historical and canonical vFW example | already available "xtestingization" to be done |
| basic_vm | python | onboarding/distribution/instantiation/Openstack check of a basic Ubuntu VM through onap-test python client | already available (used for gating and Orange daily chains check SDC/SO/AAI/SDNC using VNF_API / A la carte mode) refactoring needed to be insourced - currently hosted on gitlab.com refactoring of python client in progress in // support of GR_API to be added |
| freeradius_nbi | python | idem basic_vm except that instantiation is done through nbi module | csit test of nbi project already available (used for gating and Orange daily chains) (refactoring needed to be insourced - currently hosted on gitlab.com) |
| basic_policy | a basic test to verify policy creation/onboarding/instantiation | some starting point in existing use cases but baisc example to be implemented | |
| CDS | robot tag: cds | ||
| 5GBulk - "Data Plane" | robot tag: 5gbulkpm | A e2e test to verify 5G Bulk PM flow involving ves, message router, dfc, data router, pmmapper | Ericsson team is building script and robot tag test. |
| PNF registration | robot tag: pnf_registrate | note it is needed to run init tag before. This init tag inluclude the distribution ov vFWCL, vLB, vLB_CDS, vCPEInfra, vCPEvBNG, vCPEvBNGEMU, vCPEvGMUX,vCPEvGW which takes several minutes per distribution. So the init task may be very long and all the module are no needed for pnf_registrate. | |
| HVVES | robot tag; HVVES | ||
| scale_out | |||
| vCPE | python | Residential vCPE orchestration using software defined networking (SDN) and network functions virtualization (NFV) | Requires init tag to be run prior to usecase deployment (distributes vCPEInfra, vCPEvBNG, vCPEvBNGEMU, vCPEvGMUX,vCPEvGW) |
4) candidate-use-cases
goal: introduce new fully automated use cases
| Use case | Type (driver) | Description | Comments |
|---|---|---|---|
| 5G-OOF-SON | to be done | ||
| ... |
5) benchmarking
goal: perform resliency, robustness, stress tests
| Use case | Type (driver) | Description | Comments |
|---|---|---|---|
| LongDuration | robot tag: stability72hr | to be done based on existing 72h tests | |
| Stress | to be done | ||
| ... |
6) security
goal: perform security audits
| Use case | Type (driver) | Description | Comments |
|---|---|---|---|
| scan | to be done, a first step could consists in running free gitlab-ci security scans on existing docker files to be sync with OSJI effort | ||
| .... |