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 9 Next »

This is the tracking page for ONAP Functional Requirement of "Centralized Representation and Consistent ID of Cloud Regions"

Functional Requirement Name

Plan B, Phase 1: Centralized Representation of Cloud Regions

Plan B, Phase 2: Consistent ID of Cloud Regions

Development Status (Plan B, Phase 1: Centralized Representation of Cloud Regions)

ProjectPTLJIRA Epic / User Story*Requirements
 SO

SO-555

1,Depreciate the usage of internal representation of cloud region. Use centralized representation of cloud region in AAI instead. 


 Integration

1, Robot VM should depreciate the usage of internal representation of cloud region. Use centralized representation of cloud region in AAI instead.

2, Robot VM should allow users to specify the composite key of "{cloud-owner}, {cloud-region-id}" to execute scripts


Development Status (Plan B, Phase 2: Consistent ID of Cloud Regions)

ProjectPTLJIRA Epic / User Story*Requirements
 SO

Not committed

1,Depreciate the usage of "cloud-region-id", use the composite key of "{cloud-owner}, {cloud-region-id}" to specify a cloud region

 OOFNot committed1,Depreciate the usage of "vim-id", use the composite key of "{cloud-owner}, {cloud-region-id}" to specify a cloud region
VFCVFC-9401,Depreciate the usage of "vim-id", use the composite key of "{cloud-owner}, {cloud-region-id}" to specify a cloud region
UUIUSECASEUI-1311,Depreciate the usage of "vim-id", use the composite key of "{cloud-owner}, {cloud-region-id}" to specify a cloud region
MultiCloudMULTICLOUD-2591,Depreciate the usage of "vim-id", use the composite key of "{cloud-owner}, {cloud-region-id}" to specify a cloud region
 SDNCNot committed1,Depreciate the usage of "vim-id", use the composite key of "{cloud-owner}, {cloud-region-id}" to specify a cloud region
 VID

VID-246

1,Depreciate the usage of "vim-id", use the composite key of "{cloud-owner}, {cloud-region-id}" to specify a cloud region

*Each Requirement should be tracked by its own User Story in JIRA 

Testing Plan

Test Case 1: for "Centralized Representation of Cloud Region":

Prerequisites: SO/Integration projects accomplish the functional requirement: "Plan B, Phase 1: Centralized Representation of Cloud Region"

Step 1, Tester on-boards a VIM instance as a cloud region with ESR GUI Portal, with VIM id: cloud-owner: CloudOwner1, cloud-region-id: RegionTest.

Step 2, Tester Instantiates heat template based VF Module (vFWCL) to this cloud region with VID GUI Portal.

Step 3, Tester observes the vFWCL heat stacks are created onto the VIM instance.


Test Case 2: for "Consistent ID of Cloud Region":

Prerequisites: UUI/VFC/MultiCloud projects accomplish the functional requirement: "Plan B, Phase 2: Consistent ID of Cloud Regions"

Step 1, Tester on-boards a VIM instance as a cloud region with ESR GUI Portal, with VIM id: cloud-owner: Cloud_Owner1, cloud-region-id: RegionTest,

Step 2, Tester instantiates VNFs (a vVoLTE VNF) with UUI GUI Portal to this cloud region

Step 3, Tester observes the VNFs are created onto the VIM instance


Test Case 3: for "Consistent ID of Cloud Region"

Prerequisites: VID/SO/SDNC projects accomplish the functional requirement: "Plan B, Phase 2: Consistent ID of Cloud Regions"

Step 1, Tester on-boards a VIM instance as a cloud region with ESR GUI Portal, with VIM id: cloud-owner: Cloud_Owner1, cloud-region-id: RegionOne,

Step 2, Tester instantiates VNFs (vFWCL) with VID GUI Portal to this cloud region

Step 3, Tester observes the VNFs are created onto the VIM instance


Current Status

  1. Testing Blockers

  2. High visibility bugs
  3. Other issues for testing that should be seen at a summary level
  4. Where possible, always include JIRA links


End to End flow to be tested:

Follow Use Case vFWCL and vVoLTE respectively

Test Case 1: for "Centralized Representation of Cloud Region"

Step 1: workflow for on-boarding a VIM instance, Make sure cloudowner is "CloudOwner1"

Step 2: Follow  the orchestration workflow of Use Case vFWCL

Step 3: Login to OpenStack Horizon to verify the heat stacks for vFWCL VNFs are created as expected


Test Case 2: for "Consistent ID of Cloud Region":

Step 1: The same as Test Case 1, Step 1.  Make sure cloudowner is "Cloud_Owner1"

Step 2: Follow  the orchestration workflow of  Use Case vVoLTE

Step 3: Login to OpenStack Horizon to verify the heat stacks for vVoLTE VNFs are created as expected


Test Case 3: for "Consistent ID of Cloud Region" (Will not be ready for testing in Casablanca Release):

Step 1: The same as Test Case 1, Step 1. Make sure cloudowner is "Cloud_Owner1", cloud region id is "RegionOne"

Step 2: Follow  the orchestration workflow of  Use Case vFWCL

Step 3: Login to OpenStack Horizon to verify the heat stacks for vFWCL VNFs are created as expected


Test Cases and Status


#Test CaseStatus
101

Using ESR VIM Registration Portal, ONAP user on-boards an OpenStack Instance as cloud region with following parameters:

Cloud Owner:CloudOwner1, Cloud Region Id: RegionTest, Cloud Type: openstack, Cloud Region Version: titanium_cloud, Cloud Extra Info: {\"openstack-region-id\":\"RegionOne\"}


Note 1: The on-boarding process follows the steps described by "How-To: Register a VIM/Cloud Instance to ONAP" with one exception: The on-boarding process will not hack any SO configuration file which is depicted as "2, Register VIM/Cloud instance into SO".

Note 2: This on-boarding process should be done with updated Robot script according to INT-541

NOT YET TESTED

102

ONAP user instantiates a VF Module of vFWCL to the cloud region {CloudOwner1/RegionTest}

Refer to "ONAP Amsterdam vFW Closed Loop Demo" for detail process.

Note 1: This process can be done with existing Robot script (with enhancement to specify ID of cloud region?): ete.sh or ete-k8s.sh

NOT YET TESTED

103ONAP user logins to OpenStack Horizon and observes the HEAT stack (representing the instantiated VF Module above) is launched.

NOT YET TESTED

201The same as 101, except one parameter change: Cloud Owner: "Cloud_Owner1"

 NOT YET TESTED

202ONAP user instantiate the VNF of VoLTE use case. Refer to "VoLTE Integration Test Cases"
203ONAP user logins to OpenStack Horizon and observes the vservers (representing the instantiated VF Module above) is launched.



  • No labels