Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 21 Next »

--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.
  • CDS Blueprint Processor will implement the mount, configure and un-mount requests to SDNC after getting CONFIGURE request from SO. The processor currently has the ability to read a blueprint from archive and process it.
  • SDNC will load client cert , trusted certs and private key at deployment time. ODL should also be upgraded to Flourine SR2 version to serve above requests. The upgrade is being tracked as part of SDNC-555

JIRAs:

CCSDK-926 - Getting issue details... STATUS

CCSDK-1023 - Getting issue details... STATUS

SDNC-556 - Getting issue details... STATUS

SDNC-621 - Getting issue details... STATUS

SO-1506 - Getting issue details... STATUS

INT-885 - Getting issue details... STATUS


Deployment:

Test environment requirements for 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.
  • 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.

  1. Repo : Yet to update
  2. 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 Testcases :


#Test CaseStatus
1After PNF_READY, SO sends CONFIG-ASSIGN and CONFIGURE request to Self Service API (SS-API)


2SO Sends CONFIGURE request to SS-API
3Verify SDN-C have client cert, private key and trusted certs setup at deployment
4Connect SDN-C and PNF Simulator for configuration step
5E2E test case for NETCONF over TLS
6

Successful flow: CONFIG-ASSIGN and CONFIGURE steps will conclude as expected, and the desired configuration will be applied to the PNF; successful outcome


7Configlet(s) not found: Step deployConfig is called before assignConfig and thus the configlet was never created and persisted in the CDS database; failed outcome


8Non-existing PNF: Configuration is sent for a PNF that cannot be found on ONAP, example: IP address does not exist; failed outcome


9ODL instance not found: no ODL is available in SDN-C to respond to the Restconf requests; failed outcome


10Blueprint contains invalid configuration: the blueprint’s Restconf commands are wrong, provoking an error while sending them to ODL; failed outcome

NOT STARTED

Detailed Description End-to-End Feature Integration Testcases :

Test Case ID

Netconf_TLS_E2E_01

Test Case NameSO sends CONFIG-ASSIGN and CONFIGURE request to SS-API
DescriptionEnsure that PNF_READY notification is received by SO from simulated environment then SO sends CONFIG-ASSIGN request to SS-API
ReleaseDublin
Pre-conditions

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.

Testing Steps
StepsExpected Result
  1. Send PNF_READY to SO
  2. SO will send CONFIG-ASSIGN to SS-API
  3. Receive it and Check if it is correct
  4. Send OK response to SO
  5. SO will send CONFIGURE request to SS-API
  6. Receive it and check if it is correct
  7. Send OK response to SO

The SO accepted the "PNF_READY" Notification.

and sends out the CONFIG-ASSIGN request to SS-API

and receive an OK response from SS-API


Conclusion (Pass /Fail)
Testing Lab



Test Case IDNetconf_TLS_E2E_02
Test Case Name

Sends CONFIGURE request to SS-API

DescriptionIn this simulated CONFIG-ASSIGN request will be sent to SS-API and response will be picked to check if response is OK.
ReleaseDublin
Pre-conditions

Blueprint processor should have access to correct blueprint in archive to process it.

SDN-C should be available

Testing Steps



StepsExpected Result
  1. Sends CONFIGURE request to SS-API
  2. SS-API will receive it
  3. SS-API send CONFIGURE request to Blueprint Processor component.

  4. Component sends Mount to SDN-C
  5. Receive this request read it if it is correct
  6. Send OK 200 response

  7. Blueprint processor sends configuration request to SDN-C
  8. Receive this request read it if it is correct
  9. SDN-C sends OK 200 response

  10. Blueprint processor sends un-mount request to SDN-C
  11. Receive this request read it if it is correct
  12. SDN-C sends OK 200 response



Check for mount, configure and un-mount messages triggered by the Blueprint processor component.

Verify that messages are valid and reflect all the expected parameters.

Conclusion (Pass /Fail)
Testing Lab



Test Case IDNetconf_TLS_E2E_03
Test Case Name

Check SDN-C has client cert, private key and trusted certs setup at deployment

DescriptionSDN-C configure client cert, private key and trusted certs and deployment time. This test case verifies if all certificates are configured fine.
ReleaseDublin
Pre-conditions

SDN-C should be up and running successfully

Testing Steps



StepsExpected Result
  1. Send GET request from rest client to SDN-C for key store
  2. Verify if it has all necessary entries for Client cert, trusted certs and private key.

Get request should get all certs and private key successfully.

Conclusion (Pass /Fail)
Testing Lab


Test Case IDNetconf_TLS_E2E_04
Test Case Name

Connect SDN-C and PNF simulator for configuration step

DescriptionSDN-C/ODL will send mount , configure and un-mount request to PNF simulator and check if PNF simulator is configured successfully.
ReleaseDublin
Pre-conditions

PNF simulator should be up and running with TLS port listening. It should also be configured with Yang Models necessary for configuration request.

Testing Steps



StepsExpected Result
  1. Send mount request to SDN-C from rest client.
  2. Check for 200 OK response
  3. Send GET request for mount
  4. Check data from GET response

  5. Send configuration request to SDN-C from rest client.
  6. Check for 200 OK response
  7. Send GET request for configuration
  8. Check data from GET response

  9. Send un-mount request to SDN-C from rest client
  10. check for 200 OK response
  11. Send GET request for un-mount
  12. Check data from GET response

Get response should give correct result for mount, configure and un-mount.

Conclusion (Pass /Fail)
Testing Lab
Test Case ID

Netconf_TLS_E2E_05

Test Case NameE2E test case for NETCONF over TLS
DescriptionEnsure that PNF_READY notification is received by SO from simulated environment then SO sends CONFIG-ASSIGN, CONFIGURE request to SS-API
ReleaseDublin
Pre-conditionsSO should be waiting for PNF_READY notification after registration process and fully configured as per registration process. Blueprint archive should be configured for correct blueprint. SDNC should be installed successfully and PNF simulator should be running with TLS support.
Testing Steps
StepsExpected Result
  1. Send PNF_READY to SO(This step will trigger a run to SS-API, BP component, SDNC and PNF simulator)
  2. Send SSH mount/connect request to SDNC/ODL using rest client.
  3. Send GET request for configuration to get configuration, set in step 1.
  4. Verify received configuration is correct.
Get response should give correct result for configure


Conclusion (Pass /Fail)
Testing Lab



Test Case IDNetconf_TLS_E2E_06
Test Case Name

Successful flow

DescriptionSteps assignConfig and deployConfig will conclude as expected, and the desired configuration will be applied to the PNF
Release

Dublin

Pre-conditions

Valid PNF
Valid blueprint
SO is primed and post PNF registration stage
ODL instance is installed and available

Testing Steps



StepsExpected Result

1. SO sends a request to perform action assignConfig

blueprintName: String
blueprintVersion: Integer
action: String
pnf-name: String
pnf-ip: String

2. SS-API forwards the request to BP, 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

blueprintName: String
blueprintVersion: Integer
action: String
pnf-name: String
pnf-ip: String

4. SS-API forwards the request to Blueprint Processor, that will load the blueprint, execute the action specified, retrieve the configlet from the persistence, connect to ODL, send the configlet(s) to the PNF and return a successful message to SO


Conclusion (Pass /Fail)PASS
Testing Lab?
Test Case IDNetconf_TLS_NEG_01
Test Case Name

Configlet not found

Descriptionstep deployConfig is called before assignConfig and thus the configlet was never created and persisted in the CDS’ database
ReleaseDublin
Pre-conditions

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



StepsExpected Result


1. SO sends a request to perfom action deployConfig


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

?


Test Case IDNetconf_TLS_NEG_02
Test Case Name

Non-existing PNF

DescriptionConfiguration is called for a PNF that cannot be found on ONAP, that is, its IP address does not exist
ReleaseDublin
Pre-conditions

Valid PNF
Valid blueprint
SO is present (mocked if needed)
ODL is present (mocked if needed)

Testing Steps



StepsExpected Result


1. SO sends a request to perform action assignConfig


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


blueprintName: String
blueprintVersion: Integer
action: String
pnf-name: String
pnf-ip: String

4. SS-API forwards the request to Blueprint Processor, 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



Conclusion (Pass /Fail)
Testing Lab

?

Test Case IDNetconf_TLS_NEG_03
Test Case Name

ODL not found

DescriptionNo ODL is available in SDN-C to answer the Restconf requests
ReleaseDublin
Pre-conditions

Valid PNF
Valid blueprint
SO is present (mocked if needed)
ODL is present (mocked if needed)

Testing Steps



StepsExpected Result


1. SO sends a request to perform action assignConfig


blueprintName: String
blueprintVersion: Integer
action: String
pnf-name: String
pnf-ip: String

2. SS-API forwards the request to Blueprint Processor, 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


blueprintName: String
blueprintVersion: Integer
action: String
pnf-name: String
pnf-ip: String

4. SS-API forwards the request to Blueprint Processor, 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


Conclusion (Pass /Fail)
Testing Lab?
Test Case IDNetconf_TLS_NEG_04
Test Case Name

PNF’s blueprint contains invalid configuration

DescriptionThe blueprint’s Restconf commands are wrong, provoking an error while sending them to ODL
ReleaseDublin
Pre-conditions

Valid PNF
Valid blueprint
SO is present (mocked if needed)
ODL is present (mocked if needed)

Testing Steps



StepsExpected Result


1. SO sends a request to perform action assignConfig


blueprintName: String
blueprintVersion: Integer
action: String
pnf-name: String
pnf-ip: String


2. SS-API forwards the request to Blueprint Processor, 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


blueprintName: String
blueprintVersion: Integer
action: String
pnf-name: String
pnf-ip: String


4. SS-API forwards the request to Blueprint Processor, 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


Conclusion (Pass /Fail)
Testing Lab

?



Information:


Next Step(s):


  • No labels