summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorGary Wu <gary.i.wu@huawei.com>2018-06-07 23:42:18 +0000
committerGerrit Code Review <gerrit@onap.org>2018-06-07 23:42:18 +0000
commite8a339b4ef8d975bbb7e548e3adf76688af8f116 (patch)
tree8536da65f7d11ecf4f0c9cb2b2804d507d5ceca1
parentc5ed42a9f6bd31f65e95ede65bfaf7add4d37c30 (diff)
parentf95ee4c18ec8da681de6fceadc2017b351ac51ba (diff)
Merge "Add documentation for Change Management"
-rw-r--r--README.md36
1 files changed, 36 insertions, 0 deletions
diff --git a/README.md b/README.md
index c3a5570b..945e3d34 100644
--- a/README.md
+++ b/README.md
@@ -450,3 +450,39 @@ Each VNF has a MANIFEST.json file associated with the HEAT templates. During VNF
zip ZIP_FILE_NAME.zip *
For information about VNF onboarding via the SDC portal, please refer to the wiki page: https://wiki.onap.org/display/DW/Design
+
+NF Change Management use case
+---
+
+For the Beijing release, we focused on in-place software upgrades, with vendor-specific details encapsulated in Ansible scripts provided by NF vendors. In-place software upgrades use direct communication between the controller (SDNC or APPC) and the NF instance to trigger the software upgrade, with the upgrade executing on the instance without relinquishing any of the physical resources. Both L1 - L3 and L4+ NFs are supported in the ONAP release via SDN-C and APP-C respectively.
+The change management workflow is defined as a composition of building blocks that include locking and unlocking the NF instance, executing health checks, and executing the software upgrade.
+
+ - The CM workflow for the in-place software upgrade is defined and executed by the service orchestrator (SO).
+ - A&AI is used to lock/unlock the NF instance
+ - The pre/post health checks and software upgrade execution are implemented in App-C (L4+ NFs) and SDN-C (L1-L3 NFs) by leveraging Ansible services to communicate with the NF instances.
+ - The user (or, operator) interfaces with the CM workflow using ONAP's VID. SO communicates with A&AI using a REST API and with the controllers SDNC/APPC via DMaaP.
+
+We setup the use case demonstration for the software upgrade on the virtual gateway (vGW) as part of the vCPE use case in ONAP's Beijing release.
+The main script for invoking SO in-place software upgrade workflow is in [demo.git]/vnfs/vCPE/scripts/inPlaceSoftwareUpgrade\_vGW.txt . The workflow can be tested without VID by using this script.
+To execute the script, the user/operator would login to the SO container and copy/paste the script. One would have to install vim to edit the script and curl to execute commands within the script:
+
+ - apt-get update
+ - apt-get install vim
+ - apt-get install curl
+
+Check in VID for the available instances - service ID and instance ID - and replace those IDs in the script. Since the use case is for vGW, the controller type is SDNC.
+
+Next, the user/operator would login to the SDNC container and appropriately configure the Ansible playbooks:
+
+ - Add the ssh key of the vGW on the Ansible server
+ - Update VNF IP in DG config
+ -- docker exec -it sdnc_controller_container bash
+ - Change the following line in /opt/onap/sdnc/data/properties/lcm-dg.properties with IP of VNF:
+ -- ansible.nodelist=['10.12.5.85']
+ - Update VNF IP in Ansible Server
+ -- docker exec -ti sdnc_ansible_container /bin/bash
+ -- Add VNF IP in /opt/onap/sdnc/Playbooks/Ansible_inventory
+ - Update the Playbooks /opt/onap/sdnc/Playbooks
+ -- ansible_upgradesw@0.00.yml
+ -- ansible_precheck@0.00.yml
+ -- ansible_postcheck@0.00.yml