...
Onboard a VNF package along with a Network Service CSAR into SDC.
A video demonstration of this and example CSARs for the process "Onboarding ETSI Based NS" can be found here: SO NFVO NS Onboarding and LCM Demonstrations
It is recommended that you view this video before/alongside this section of the guide.
...
3: Now you will need to add the Network Service CSAR package to this service. You can do this by clicking in the blank whitespace of the composition, then on the right hand side of the page select the 2nd tab in order to add a deployment artifact. Click "ADD ARTIFACT" here, give an "Artifact Label" of "ns", any description value and ensure you choose a "Type" of "OTHER". Then click "DONE".you choose a "Type" of "OTHER". Then click "DONE".
Please note, in the Honolulu release of ONAP, the "OTHER" type has been removed. However it is simple to add the type back through the SDC-backend Pod, you can edit this at runtime for the "SDC-BE" pod.
Simply exec into the "sdc-be" pod on your ONAP deployment, then you will need to edit the following file: /var/lib/jetty/config/catalog-be/configuration.yaml
Find the following section in the configuration.yaml:
| Code Block |
|---|
- type: OTHER
categories:
- DEPLOYMENT
- INFORMATIONAL
componentTypes:
- RESOURCE
resourceTypes:
- VFC
- CVFC
- CP
- VL
- VF
- VFCMT
- Abstract
- PNF |
You will then need to add "- SERVICE" under the "componentTypes:" heading above. This will immediately add the OTHER type into your SDC deployment. Your file should look as follows:
| Code Block |
|---|
- type: OTHER
categories:
- DEPLOYMENT
- INFORMATIONAL
componentTypes:
- RESOURCE
- SERVICE
resourceTypes:
- VFC
- CVFC
- CP
- VL
- VF
- VFCMT
- Abstract
- PNF |
Please note, you will need to complete this workaround again if the SDC-BE pod is restarted for any reason.
Alternatively, you can edit the configuration file before deployment by editting this file in the Helm Charts:
sdc/src/main/docker/backend/chef-repo/cookbooks/sdc-catalog-be/templates/default/BE-configuration.yaml
4: Finally you can click "Certify" in the top right hand corner, followed by "Distribute". Your Service will now distributed across ONAP.
...
This section of this guide can be seen in video format at the following link: https://wikilf-onap.onapatlassian.orgnet/wiki/display/DW/SO+NFVO+NS+Onboarding+and+LCM+Demonstrations
It is recommended that you view the "ETSI Based NS Orchestration Demo" video before/alongside this section of the guide.
...
You should receive a synchronous response back with a 201 Create HTTP Response. This response will contain the NS Instance ID of the NS Instance we just created, take note of this as it will be needed in the following steps.
...
This will trigger the Asynchronous Instantiate NS Functionality. You will receive a response confirming that the process has begun with a 201 202 Accepted HTTP Response Header. You can view the debug.log files on the following pods in order to view the progress:
...
Similar to the Instantiate functionality, this is an asynchronous call, so you will receive a response confirming that the process has begun with a 201 202 Accepted HTTP Response Header. As above, view the specified debug.log files in order to view the progress.
...
Similar to the Create functionality, this is a synchronous call and as such you will receive the actual job response a 204 No Content Http Response to your CURL command.
Once the full deletion has been completed, reconnect to the "NFVO" database, within the Marie-Db-Galera-0 pod on your ONAP deployment. Retrieving all data from the "ns_inst" table again, you should no longer be able to see the NS Instance in the NS_INST table.
...