Overview:
The E2E integration test consists
--TEST STATUS for Dublin Release ----
The Netconf configuration over TLS use case consists of three main parts:
- SO will implement two more steps in workflow CONFIG-ASSIGN and CONFIGURE step.
- Blueprint processor in CC-SDK will implement a way to send mount , configure and un-mount request to SDNC after getting CONFIGURE request from SO. It currently have ability to read any blueprint from archieve and process it.
- SDNC will load client cert , trusted certs and private key at deployment time. ODL is also upgraded to Flourine SR2 version to serve above requests.l for Dublin release)
JIRAs:
Jira | ||||||||
---|---|---|---|---|---|---|---|---|
|
Jira | ||||||||
---|---|---|---|---|---|---|---|---|
|
Jira | ||||||||
---|---|---|---|---|---|---|---|---|
|
Jira | ||||||||
---|---|---|---|---|---|---|---|---|
|
Jira | ||||||||
---|---|---|---|---|---|---|---|---|
|
Jira | ||||||||
---|---|---|---|---|---|---|---|---|
|
Gliffy Diagram | ||||||||
---|---|---|---|---|---|---|---|---|
|
Deployment:
Test environment requirements for above the test cases:
- xNF simulator for test cases: PNF Simulator with TLS & YANG support.Rest Client simulator.
- SO with Config-Assign and Configure steps implemented in workflows.
- CC-SDK, CDS Blueprint processor enhanced so that it can send mount, configure and un-mount rest request to SDNC.
- SDNC enhanced with ODL flourine SR2 and also capable to import client and trusted certificate and private key at deployment time.
This environment can be set up by following the steps below.
- Repo : Yet to update
- RUN : Yet to update
Use Case preconditions:
- xNF simulator.Rest Client sim.
E2E Netconf config over TLS Sequence Diagram
High Level End-to-End feature integration
Test cases :
# | Test Case |
---|
Description |
---|
Successful flow: both steps will conclude as expected, and the desired configuration will be applied to the PNF; successful outcome
Reference | Tester | |||
---|---|---|---|---|
1 | Create and distribute service which contains PNF | Verify distribution and ingestion of PNF service csar to VID, AAI & SO. | 5G - PNF Onboarding Test Cases and Status : PNF-OB-5 | Andy Walshe |
2 | Waiting for PNFReady | Verification if PNF PnP functionality within SO is waiting for PNFReady to be published by PRH. | 5G - PNF PnP -WaitingforPNFReady | |
3 | PNF registration accepted | Verification if PNF resource registration is done properly | 5G : Configuration with NETCONF - E2E test case for Netconf over TLS | |
4 | Send Configuration with NETCONF over TLS | Verify the configuration is sent to the PNF with NETCONF | 5G : Configuration with NETCONF - Success Flow |
Detailed Description End-to-End Feature Integration Testcases :
Test Case ID | NETCONF_CONFIGURATION_TLS_E2E |
---|
Detailed Description End-to-End Feature Integration Testcases :
Netconf_TLS_E2E_01
SO should be waiting for PNF_READY notification after registration process and fully configured as per registration process.
Follow the 5G - PNF PnP - Integration Test Cases T01, T02, T03, T04 to complete the PNF registration and waiting for the PNF_READY notification.
- Send PNF_READY to SO
- SO will send CONFIG-ASSIGN to SS-API
- Receive it and Check if it is correct
- Send OK response to SO
- SO will send CONFIGURE request to SS-API
- Receive it and check if it is correct
- Send OK response to SO
The SO accepted the "PNF_READY" Notification.
and sends out the CONFIG-ASSIGN request to SS-APIand receive an OK response from SS-API
Sends CONFIGURE request to SS-API
BP processor should have access to correct blueprint in archive to process it. SDNC should b
Testing Steps
Check for mount, configure and un-mount messages coming out of
BP proc. Verify that they are correct.
Check SDNC have client cert, private key and trusted certs setup at deployment
SDNC should be up and running successfully
Testing Steps
Steps | Expected Result |
---|---|
| Get request should get all certs and private key successfully. |
Connect SDNC and PNF sim for configuration step
PNF sim should be up and running with TLS port listening. It should also be configured with Yang Models necessary for configuration request.
Testing Steps
Get response should give correct result for mount, configure and un-mount.
Test Case Name | E2E test case for NETCONF over TLS |
Description | Ensure that PNF_READY notification is received by SO from |
PRH then SO sends CONFIG-ASSIGN, CONFIGURE request to SS-API, to configure the xNF | |
Release | Dublin |
Pre-conditions |
|
Install pnf simulator from here using ./simulator.sh start. It will start simulator in TLS/SSH mode at 6503/830 port. Send VES message by changing config/config.json. | ||||
Testing Steps |
|
|
|
Successful flow
Dublin
Valid PNF
Valid blueprint
SO is present (mocked if needed)
ODL is present (mocked if needed)
Testing Steps
1. SO sends a request to perform action assignConfig
Code Block | ||
---|---|---|
| ||
blueprintName: String
blueprintVersion: Integer
action: String
pnf-name: String
pnf-ip: String |
2. SS-API forwards the request to BPP, that will load the blueprint, execute the action specified, prepare the configlet, persist it and return a successful message to SO
3. SO recognizes the success message and sends a request to perfom action deployConfig
Code Block | ||
---|---|---|
| ||
blueprintName: String
blueprintVersion: Integer
action: String
pnf-name: String
pnf-ip: String |
4. SS-API forwards the request to BPP, that will load the blueprint, execute the action specified, retrieve the configlet from the persistence, connect to ODL, send the configlet to the PNF and return a successful message to SO
Configlet not found
Valid Blueprint
SO is present (mocked if needed)
To ensure that there is no previous persisted configlet, this should be the first test to be ran
Testing Steps
1. SO sends a request to perfom action deployConfig
Code Block | ||
---|---|---|
| ||
blueprintName: String
blueprintVersion: Integer
action: String
pnf-name: String
pnf-ip: String |
2. SS-API forwards the request to BPP, that will load the blueprint and execute the action specified. As part of the action executon, BPP will try to retrieve the configlet from the CDS’ persistence, but it will fail since the assignConfig step did not happen before
3. An error message will be sent to SO
?
| |||||||
Conclusion (Pass /Fail) |
| ||||||
Testing Lab | Ericsson Lab, Windriver Lab |
Non-existing PNF
Valid PNF
Valid blueprint
SO is present (mocked if needed)
ODL is present (mocked if needed)
Testing Steps
1. SO sends a request to perform action assignConfig
Code Block | ||
---|---|---|
| ||
blueprintName: String
blueprintVersion: Integer
action: String
pnf-name: String
pnf-ip: String |
2. SS-API forwards the request to BPP, that will load the blueprint, execute the action specified, prepare the configlet, persist it and return a successful message to SO
3. SO recognizes the success message and sends a request to perfom action deployConfig
Code Block | ||
---|---|---|
| ||
blueprintName: String
blueprintVersion: Integer
action: String
pnf-name: String
pnf-ip: String |
4. SS-API forwards the request to BPP, that will load the blueprint, execute the action specified and retrieve the configlet from the persistence
5. The next step is to mount a Netconf server in the PNF, through ODL. Since the IP address of the PNF is not valid, ODL won’t be able to connect to the PNF, failing the operation
6. An error message will be sent to SO
?
ODL not found
Valid PNF
Valid blueprint
SO is present (mocked if needed)
ODL is present (mocked if needed)
Testing Steps
1. SO sends a request to perform action assignConfig
Code Block | ||
---|---|---|
| ||
blueprintName: String
blueprintVersion: Integer
action: String
pnf-name: String
pnf-ip: String |
2. SS-API forwards the request to BPP, that will load the blueprint, execute the action specified, prepare the configlet, persist it and return a successful message to SO
3. SO recognizes the success message and sends a request to perfom action deployConfig
Code Block | ||
---|---|---|
| ||
blueprintName: String
blueprintVersion: Integer
action: String
pnf-name: String
pnf-ip: String |
4. SS-API forwards the request to BPP, that will load the blueprint, execute the action specified and retrieve the configlet from the persistence
5. The next step is to mount a Netconf server in the PNF, through ODL. Since there is no ODL available, such connection cannot be established
6. An error message will be sent to SO
PNF’s blueprint contains invalid configuration
Valid PNF
Valid blueprint
SO is present (mocked if needed)
ODL is present (mocked if needed)
Testing Steps
1. SO sends a request to perform action assignConfig
Code Block | ||
---|---|---|
| ||
blueprintName: String
blueprintVersion: Integer
action: String
pnf-name: String
pnf-ip: String |
2. SS-API forwards the request to BPP, that will load the blueprint, execute the action specified, prepare the configlet, persist it and return a successful message to SO
3. SO recognizes the success message and sends a request to perfom action deployConfig
Code Block | ||
---|---|---|
| ||
blueprintName: String
blueprintVersion: Integer
action: String
pnf-name: String
pnf-ip: String |
4. SS-API forwards the request to BPP, that will load the blueprint, execute the action specified, retrieve the configlet from the persistence, connect to ODL and send the configlet to the PNF
5. Since the configlet is not valid, ODL will return an error after receiving the Restconf request
6. An error message will be sent to SO
Information:
Next Step(s):