From 2706a51d340e612730210adb5a521b6e01fde46d Mon Sep 17 00:00:00 2001 From: Aric Gardner Date: Fri, 10 Apr 2020 16:21:31 -0400 Subject: Fix Directories with spaces and ' Directories with spaces and ' break intersphinx linking Issue-ID: CIMAN-376 Signed-off-by: Aric Gardner Change-Id: Idf41f31e6da9a60c10c7b6c2e3cc68f0a6d47d80 --- docs/APPC CDT Guide/APPC CDT Guide.rst | 1141 ------- .../Generic 1802 User Input Spreadsheet v.02.xlsx | Bin 397973 -> 0 bytes docs/APPC CDT Guide/media/image0.png | Bin 143619 -> 0 bytes docs/APPC CDT Guide/media/image1.png | Bin 92941 -> 0 bytes docs/APPC CDT Guide/media/image10.png | Bin 161038 -> 0 bytes docs/APPC CDT Guide/media/image11.png | Bin 163785 -> 0 bytes docs/APPC CDT Guide/media/image12.png | Bin 168893 -> 0 bytes docs/APPC CDT Guide/media/image13.png | Bin 163047 -> 0 bytes docs/APPC CDT Guide/media/image14.png | Bin 172622 -> 0 bytes docs/APPC CDT Guide/media/image15.png | Bin 227636 -> 0 bytes docs/APPC CDT Guide/media/image15a.png | Bin 177067 -> 0 bytes docs/APPC CDT Guide/media/image15b.png | Bin 152827 -> 0 bytes docs/APPC CDT Guide/media/image15c.png | Bin 156320 -> 0 bytes docs/APPC CDT Guide/media/image15d.png | Bin 162581 -> 0 bytes docs/APPC CDT Guide/media/image15e.png | Bin 157336 -> 0 bytes docs/APPC CDT Guide/media/image15f.png | Bin 155737 -> 0 bytes docs/APPC CDT Guide/media/image16.png | Bin 244692 -> 0 bytes docs/APPC CDT Guide/media/image17.png | Bin 213518 -> 0 bytes docs/APPC CDT Guide/media/image18.png | Bin 171016 -> 0 bytes docs/APPC CDT Guide/media/image19.png | Bin 130212 -> 0 bytes docs/APPC CDT Guide/media/image2.png | Bin 138015 -> 0 bytes docs/APPC CDT Guide/media/image20.png | Bin 232234 -> 0 bytes docs/APPC CDT Guide/media/image21.png | Bin 122848 -> 0 bytes docs/APPC CDT Guide/media/image23.png | Bin 214188 -> 0 bytes docs/APPC CDT Guide/media/image24.png | Bin 155687 -> 0 bytes docs/APPC CDT Guide/media/image26.png | Bin 168504 -> 0 bytes docs/APPC CDT Guide/media/image27.png | Bin 148849 -> 0 bytes docs/APPC CDT Guide/media/image28.png | Bin 177667 -> 0 bytes docs/APPC CDT Guide/media/image29.png | Bin 234595 -> 0 bytes docs/APPC CDT Guide/media/image3.png | Bin 130209 -> 0 bytes docs/APPC CDT Guide/media/image30.png | Bin 212685 -> 0 bytes docs/APPC CDT Guide/media/image30a.png | Bin 179848 -> 0 bytes docs/APPC CDT Guide/media/image31.png | Bin 129285 -> 0 bytes docs/APPC CDT Guide/media/image32.png | Bin 96870 -> 0 bytes docs/APPC CDT Guide/media/image33.png | Bin 133699 -> 0 bytes docs/APPC CDT Guide/media/image34.png | Bin 136853 -> 0 bytes docs/APPC CDT Guide/media/image35.png | Bin 259245 -> 0 bytes docs/APPC CDT Guide/media/image36.png | Bin 160763 -> 0 bytes docs/APPC CDT Guide/media/image37.png | Bin 18643 -> 0 bytes docs/APPC CDT Guide/media/image38.png | Bin 57387 -> 0 bytes docs/APPC CDT Guide/media/image39.png | Bin 110 -> 0 bytes docs/APPC CDT Guide/media/image4.png | Bin 133181 -> 0 bytes docs/APPC CDT Guide/media/image40.png | Bin 21622 -> 0 bytes docs/APPC CDT Guide/media/image41.png | Bin 500 -> 0 bytes docs/APPC CDT Guide/media/image42.png | Bin 75389 -> 0 bytes docs/APPC CDT Guide/media/image5.png | Bin 94423 -> 0 bytes docs/APPC CDT Guide/media/image6.png | Bin 62694 -> 0 bytes docs/APPC CDT Guide/media/image7.png | Bin 130021 -> 0 bytes docs/APPC CDT Guide/media/image8.png | Bin 74987 -> 0 bytes docs/APPC CDT Guide/media/image9.png | Bin 107306 -> 0 bytes docs/APPC CDT Guide/media/imageA.png | Bin 14058 -> 0 bytes .../APPC Client Library Guide.rst | 224 -- docs/APPC Client Library Guide/image2.png | Bin 48033 -> 0 bytes docs/APPC LCM API Guide/APPC LCM API Guide.rst | 3098 -------------------- docs/APPC Logging Guide/APPC Logging Guide.rst | 334 --- .../APPCLoggingArchitecturediagram.png | Bin 119759 -> 0 bytes docs/APPC OAM API Guide/APPC OAM API Guide.rst | 548 ---- .../APPC OAM API Guide/media/AppcAPIdocdiagram.png | Bin 115899 -> 0 bytes docs/APPC User Guide/APPC User Guide.rst | 1325 --------- docs/APPC User Guide/media/AppCApidoxExplorer.png | Bin 121129 -> 0 bytes docs/APPC User Guide/media/AppCApidoxExplorer2.png | Bin 138757 -> 0 bytes docs/APPC User Guide/media/AppCApidoxExplorer3.png | Bin 127949 -> 0 bytes docs/APPC User Guide/media/AppCApidoxExplorer4.png | Bin 128237 -> 0 bytes .../media/AppCArchitectureDiagram.png | Bin 95698 -> 0 bytes .../media/AppCDGOrchestratorArchitecture.png | Bin 67196 -> 0 bytes docs/APPC User Guide/media/AppCDeployment.png | Bin 46358 -> 0 bytes docs/APPC-CTD-Guide/APPC-CDT-Guide.rst | 1141 +++++++ .../Generic 1802 User Input Spreadsheet v.02.xlsx | Bin 0 -> 397973 bytes docs/APPC-CTD-Guide/media/image0.png | Bin 0 -> 143619 bytes docs/APPC-CTD-Guide/media/image1.png | Bin 0 -> 92941 bytes docs/APPC-CTD-Guide/media/image10.png | Bin 0 -> 161038 bytes docs/APPC-CTD-Guide/media/image11.png | Bin 0 -> 163785 bytes docs/APPC-CTD-Guide/media/image12.png | Bin 0 -> 168893 bytes docs/APPC-CTD-Guide/media/image13.png | Bin 0 -> 163047 bytes docs/APPC-CTD-Guide/media/image14.png | Bin 0 -> 172622 bytes docs/APPC-CTD-Guide/media/image15.png | Bin 0 -> 227636 bytes docs/APPC-CTD-Guide/media/image15a.png | Bin 0 -> 177067 bytes docs/APPC-CTD-Guide/media/image15b.png | Bin 0 -> 152827 bytes docs/APPC-CTD-Guide/media/image15c.png | Bin 0 -> 156320 bytes docs/APPC-CTD-Guide/media/image15d.png | Bin 0 -> 162581 bytes docs/APPC-CTD-Guide/media/image15e.png | Bin 0 -> 157336 bytes docs/APPC-CTD-Guide/media/image15f.png | Bin 0 -> 155737 bytes docs/APPC-CTD-Guide/media/image16.png | Bin 0 -> 244692 bytes docs/APPC-CTD-Guide/media/image17.png | Bin 0 -> 213518 bytes docs/APPC-CTD-Guide/media/image18.png | Bin 0 -> 171016 bytes docs/APPC-CTD-Guide/media/image19.png | Bin 0 -> 130212 bytes docs/APPC-CTD-Guide/media/image2.png | Bin 0 -> 138015 bytes docs/APPC-CTD-Guide/media/image20.png | Bin 0 -> 232234 bytes docs/APPC-CTD-Guide/media/image21.png | Bin 0 -> 122848 bytes docs/APPC-CTD-Guide/media/image23.png | Bin 0 -> 214188 bytes docs/APPC-CTD-Guide/media/image24.png | Bin 0 -> 155687 bytes docs/APPC-CTD-Guide/media/image26.png | Bin 0 -> 168504 bytes docs/APPC-CTD-Guide/media/image27.png | Bin 0 -> 148849 bytes docs/APPC-CTD-Guide/media/image28.png | Bin 0 -> 177667 bytes docs/APPC-CTD-Guide/media/image29.png | Bin 0 -> 234595 bytes docs/APPC-CTD-Guide/media/image3.png | Bin 0 -> 130209 bytes docs/APPC-CTD-Guide/media/image30.png | Bin 0 -> 212685 bytes docs/APPC-CTD-Guide/media/image30a.png | Bin 0 -> 179848 bytes docs/APPC-CTD-Guide/media/image31.png | Bin 0 -> 129285 bytes docs/APPC-CTD-Guide/media/image32.png | Bin 0 -> 96870 bytes docs/APPC-CTD-Guide/media/image33.png | Bin 0 -> 133699 bytes docs/APPC-CTD-Guide/media/image34.png | Bin 0 -> 136853 bytes docs/APPC-CTD-Guide/media/image35.png | Bin 0 -> 259245 bytes docs/APPC-CTD-Guide/media/image36.png | Bin 0 -> 160763 bytes docs/APPC-CTD-Guide/media/image37.png | Bin 0 -> 18643 bytes docs/APPC-CTD-Guide/media/image38.png | Bin 0 -> 57387 bytes docs/APPC-CTD-Guide/media/image39.png | Bin 0 -> 110 bytes docs/APPC-CTD-Guide/media/image4.png | Bin 0 -> 133181 bytes docs/APPC-CTD-Guide/media/image40.png | Bin 0 -> 21622 bytes docs/APPC-CTD-Guide/media/image41.png | Bin 0 -> 500 bytes docs/APPC-CTD-Guide/media/image42.png | Bin 0 -> 75389 bytes docs/APPC-CTD-Guide/media/image5.png | Bin 0 -> 94423 bytes docs/APPC-CTD-Guide/media/image6.png | Bin 0 -> 62694 bytes docs/APPC-CTD-Guide/media/image7.png | Bin 0 -> 130021 bytes docs/APPC-CTD-Guide/media/image8.png | Bin 0 -> 74987 bytes docs/APPC-CTD-Guide/media/image9.png | Bin 0 -> 107306 bytes docs/APPC-CTD-Guide/media/imageA.png | Bin 0 -> 14058 bytes .../APPC-Client-Library-Guide.rst | 224 ++ docs/APPC-Client-Library-Guide/image2.png | Bin 0 -> 48033 bytes docs/APPC-LCM-API-Guide/APPC-LCM-API-Guide.rst | 3098 ++++++++++++++++++++ docs/APPC-Logging-Guide/APPC-Logging-Guide.rst | 334 +++ .../APPCLoggingArchitecturediagram.png | Bin 0 -> 119759 bytes docs/APPC-OAM-API-Guide/APPC-OAM-API-Guide.rst | 548 ++++ .../APPC-OAM-API-Guide/media/AppcAPIdocdiagram.png | Bin 0 -> 115899 bytes docs/APPC-User-Guide/APPC-User-Guide.rst | 1325 +++++++++ docs/APPC-User-Guide/media/AppCApidoxExplorer.png | Bin 0 -> 121129 bytes docs/APPC-User-Guide/media/AppCApidoxExplorer2.png | Bin 0 -> 138757 bytes docs/APPC-User-Guide/media/AppCApidoxExplorer3.png | Bin 0 -> 127949 bytes docs/APPC-User-Guide/media/AppCApidoxExplorer4.png | Bin 0 -> 128237 bytes .../media/AppCArchitectureDiagram.png | Bin 0 -> 95698 bytes .../media/AppCDGOrchestratorArchitecture.png | Bin 0 -> 67196 bytes docs/APPC-User-Guide/media/AppCDeployment.png | Bin 0 -> 46358 bytes docs/index.rst | 12 +- 133 files changed, 6676 insertions(+), 6676 deletions(-) delete mode 100644 docs/APPC CDT Guide/APPC CDT Guide.rst delete mode 100644 docs/APPC CDT Guide/Generic 1802 User Input Spreadsheet v.02.xlsx delete mode 100644 docs/APPC CDT Guide/media/image0.png delete mode 100644 docs/APPC CDT Guide/media/image1.png delete mode 100644 docs/APPC CDT Guide/media/image10.png delete mode 100644 docs/APPC CDT Guide/media/image11.png delete mode 100644 docs/APPC CDT Guide/media/image12.png delete mode 100644 docs/APPC CDT Guide/media/image13.png delete mode 100644 docs/APPC CDT Guide/media/image14.png delete mode 100644 docs/APPC CDT Guide/media/image15.png delete mode 100644 docs/APPC CDT Guide/media/image15a.png delete mode 100644 docs/APPC CDT Guide/media/image15b.png delete mode 100644 docs/APPC CDT Guide/media/image15c.png delete mode 100644 docs/APPC CDT Guide/media/image15d.png delete mode 100644 docs/APPC CDT Guide/media/image15e.png delete mode 100644 docs/APPC CDT Guide/media/image15f.png delete mode 100644 docs/APPC CDT Guide/media/image16.png delete mode 100644 docs/APPC CDT Guide/media/image17.png delete mode 100644 docs/APPC CDT Guide/media/image18.png delete mode 100644 docs/APPC CDT Guide/media/image19.png delete mode 100644 docs/APPC CDT Guide/media/image2.png delete mode 100644 docs/APPC CDT Guide/media/image20.png delete mode 100644 docs/APPC CDT Guide/media/image21.png delete mode 100644 docs/APPC CDT Guide/media/image23.png delete mode 100644 docs/APPC CDT Guide/media/image24.png delete mode 100644 docs/APPC CDT Guide/media/image26.png delete mode 100644 docs/APPC CDT Guide/media/image27.png delete mode 100644 docs/APPC CDT Guide/media/image28.png delete mode 100644 docs/APPC CDT Guide/media/image29.png delete mode 100644 docs/APPC CDT Guide/media/image3.png delete mode 100644 docs/APPC CDT Guide/media/image30.png delete mode 100644 docs/APPC CDT Guide/media/image30a.png delete mode 100644 docs/APPC CDT Guide/media/image31.png delete mode 100644 docs/APPC CDT Guide/media/image32.png delete mode 100644 docs/APPC CDT Guide/media/image33.png delete mode 100644 docs/APPC CDT Guide/media/image34.png delete mode 100644 docs/APPC CDT Guide/media/image35.png delete mode 100644 docs/APPC CDT Guide/media/image36.png delete mode 100644 docs/APPC CDT Guide/media/image37.png delete mode 100644 docs/APPC CDT Guide/media/image38.png delete mode 100644 docs/APPC CDT Guide/media/image39.png delete mode 100644 docs/APPC CDT Guide/media/image4.png delete mode 100644 docs/APPC CDT Guide/media/image40.png delete mode 100644 docs/APPC CDT Guide/media/image41.png delete mode 100644 docs/APPC CDT Guide/media/image42.png delete mode 100644 docs/APPC CDT Guide/media/image5.png delete mode 100644 docs/APPC CDT Guide/media/image6.png delete mode 100644 docs/APPC CDT Guide/media/image7.png delete mode 100644 docs/APPC CDT Guide/media/image8.png delete mode 100644 docs/APPC CDT Guide/media/image9.png delete mode 100644 docs/APPC CDT Guide/media/imageA.png delete mode 100644 docs/APPC Client Library Guide/APPC Client Library Guide.rst delete mode 100644 docs/APPC Client Library Guide/image2.png delete mode 100644 docs/APPC LCM API Guide/APPC LCM API Guide.rst delete mode 100644 docs/APPC Logging Guide/APPC Logging Guide.rst delete mode 100644 docs/APPC Logging Guide/APPCLoggingArchitecturediagram.png delete mode 100644 docs/APPC OAM API Guide/APPC OAM API Guide.rst delete mode 100644 docs/APPC OAM API Guide/media/AppcAPIdocdiagram.png delete mode 100644 docs/APPC User Guide/APPC User Guide.rst delete mode 100644 docs/APPC User Guide/media/AppCApidoxExplorer.png delete mode 100644 docs/APPC User Guide/media/AppCApidoxExplorer2.png delete mode 100644 docs/APPC User Guide/media/AppCApidoxExplorer3.png delete mode 100644 docs/APPC User Guide/media/AppCApidoxExplorer4.png delete mode 100644 docs/APPC User Guide/media/AppCArchitectureDiagram.png delete mode 100644 docs/APPC User Guide/media/AppCDGOrchestratorArchitecture.png delete mode 100644 docs/APPC User Guide/media/AppCDeployment.png create mode 100644 docs/APPC-CTD-Guide/APPC-CDT-Guide.rst create mode 100644 docs/APPC-CTD-Guide/Generic 1802 User Input Spreadsheet v.02.xlsx create mode 100644 docs/APPC-CTD-Guide/media/image0.png create mode 100644 docs/APPC-CTD-Guide/media/image1.png create mode 100644 docs/APPC-CTD-Guide/media/image10.png create mode 100644 docs/APPC-CTD-Guide/media/image11.png create mode 100644 docs/APPC-CTD-Guide/media/image12.png create mode 100644 docs/APPC-CTD-Guide/media/image13.png create mode 100644 docs/APPC-CTD-Guide/media/image14.png create mode 100644 docs/APPC-CTD-Guide/media/image15.png create mode 100644 docs/APPC-CTD-Guide/media/image15a.png create mode 100644 docs/APPC-CTD-Guide/media/image15b.png create mode 100644 docs/APPC-CTD-Guide/media/image15c.png create mode 100644 docs/APPC-CTD-Guide/media/image15d.png create mode 100644 docs/APPC-CTD-Guide/media/image15e.png create mode 100644 docs/APPC-CTD-Guide/media/image15f.png create mode 100644 docs/APPC-CTD-Guide/media/image16.png create mode 100644 docs/APPC-CTD-Guide/media/image17.png create mode 100644 docs/APPC-CTD-Guide/media/image18.png create mode 100644 docs/APPC-CTD-Guide/media/image19.png create mode 100644 docs/APPC-CTD-Guide/media/image2.png create mode 100644 docs/APPC-CTD-Guide/media/image20.png create mode 100644 docs/APPC-CTD-Guide/media/image21.png create mode 100644 docs/APPC-CTD-Guide/media/image23.png create mode 100644 docs/APPC-CTD-Guide/media/image24.png create mode 100644 docs/APPC-CTD-Guide/media/image26.png create mode 100644 docs/APPC-CTD-Guide/media/image27.png create mode 100644 docs/APPC-CTD-Guide/media/image28.png create mode 100644 docs/APPC-CTD-Guide/media/image29.png create mode 100644 docs/APPC-CTD-Guide/media/image3.png create mode 100644 docs/APPC-CTD-Guide/media/image30.png create mode 100644 docs/APPC-CTD-Guide/media/image30a.png create mode 100644 docs/APPC-CTD-Guide/media/image31.png create mode 100644 docs/APPC-CTD-Guide/media/image32.png create mode 100644 docs/APPC-CTD-Guide/media/image33.png create mode 100644 docs/APPC-CTD-Guide/media/image34.png create mode 100644 docs/APPC-CTD-Guide/media/image35.png create mode 100644 docs/APPC-CTD-Guide/media/image36.png create mode 100644 docs/APPC-CTD-Guide/media/image37.png create mode 100644 docs/APPC-CTD-Guide/media/image38.png create mode 100644 docs/APPC-CTD-Guide/media/image39.png create mode 100644 docs/APPC-CTD-Guide/media/image4.png create mode 100644 docs/APPC-CTD-Guide/media/image40.png create mode 100644 docs/APPC-CTD-Guide/media/image41.png create mode 100644 docs/APPC-CTD-Guide/media/image42.png create mode 100644 docs/APPC-CTD-Guide/media/image5.png create mode 100644 docs/APPC-CTD-Guide/media/image6.png create mode 100644 docs/APPC-CTD-Guide/media/image7.png create mode 100644 docs/APPC-CTD-Guide/media/image8.png create mode 100644 docs/APPC-CTD-Guide/media/image9.png create mode 100644 docs/APPC-CTD-Guide/media/imageA.png create mode 100644 docs/APPC-Client-Library-Guide/APPC-Client-Library-Guide.rst create mode 100644 docs/APPC-Client-Library-Guide/image2.png create mode 100644 docs/APPC-LCM-API-Guide/APPC-LCM-API-Guide.rst create mode 100644 docs/APPC-Logging-Guide/APPC-Logging-Guide.rst create mode 100644 docs/APPC-Logging-Guide/APPCLoggingArchitecturediagram.png create mode 100644 docs/APPC-OAM-API-Guide/APPC-OAM-API-Guide.rst create mode 100644 docs/APPC-OAM-API-Guide/media/AppcAPIdocdiagram.png create mode 100644 docs/APPC-User-Guide/APPC-User-Guide.rst create mode 100644 docs/APPC-User-Guide/media/AppCApidoxExplorer.png create mode 100644 docs/APPC-User-Guide/media/AppCApidoxExplorer2.png create mode 100644 docs/APPC-User-Guide/media/AppCApidoxExplorer3.png create mode 100644 docs/APPC-User-Guide/media/AppCApidoxExplorer4.png create mode 100644 docs/APPC-User-Guide/media/AppCArchitectureDiagram.png create mode 100644 docs/APPC-User-Guide/media/AppCDGOrchestratorArchitecture.png create mode 100644 docs/APPC-User-Guide/media/AppCDeployment.png (limited to 'docs') diff --git a/docs/APPC CDT Guide/APPC CDT Guide.rst b/docs/APPC CDT Guide/APPC CDT Guide.rst deleted file mode 100644 index cd06fe7a8..000000000 --- a/docs/APPC CDT Guide/APPC CDT Guide.rst +++ /dev/null @@ -1,1141 +0,0 @@ -.. ============LICENSE_START========================================== -.. =================================================================== -.. Copyright © 2018 AT&T Intellectual Property. All rights reserved. -.. =================================================================== -.. Licensed under the Creative Commons License, Attribution 4.0 Intl. (the "License"); -.. you may not use this documentation except in compliance with the License. -.. You may obtain a copy of the License at -.. -.. https://creativecommons.org/licenses/by/4.0/ -.. -.. Unless required by applicable law or agreed to in writing, software -.. distributed under the License is distributed on an "AS IS" BASIS, -.. WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. -.. See the License for the specific language governing permissions and -.. limitations under the License. -.. ============LICENSE_END============================================ - -.. _appc_cdt_guide: - -=================== -APPC CDT User Guide -=================== - -Introduction -============ - -This document is the APPC Controller Design Tool (CDT) User Guide for self-service -onboarding of VNF’s. VNF owners can create templates and other artifacts -for APPC Configure command (used to apply a post-instantiation -configuration) as well as other life cycle commands. - -A complete list of all APPC supported commands is contained in the -APPC LCM API Guide available on onap.readthedocs.io. - -Overview of APPC Support for VNF Configuration and Lifecycle Commands -====================================================================== - -APPC is an ONAP component that performs functions to manage the -lifecycle of VNF’s and their component. The picture below summarizes the -APP-C design intent. - -|image0| - -Some lifecycle commands are supported on any VNF type, such as commands -executed using OpenStack or for generic REST calls such as for -HealthCheck. Other commands require models called templates to be -created in the APPC Controller Design Tool(CDT) by the VNF owner. - -Templates are needed for lifecycle commands such as for -post-instantiation configuration and for passing payloads to a Chef or -Ansible server. Templates contain static and instance-specific -parameters in a structured language (currently limited to xml and JSON). -The APPC CDT allows a VNF technology owner to identify the -instance specific parameters with a unique name. - -At run time, the instance specific parameter values are populated in the -template to replace the parameter name. - -|image1| - -|image2| - -|image3| - -Overview of the Onboarding Process -================================== - -Pre-Requisites for Onboarding: ------------------------------- - -- The VNF must support the below listed device protocols along with OpenStack for VM-level commands: - - Netconf, - - Chef, - - Ansible, - - REST - The REST protocol is used for REST interfaces to a VNF. Currently, the only action that can use REST is HealthCheck. - - RESTCONF - The RESTCONF protocal is used only for VNFs that support Netconf and are able to be mounted in OpenDayLight (ODL). Use the protocal NETCONF-XML if the VNF is not ODL mountable. - -- In order to build the templates needed for lifecycle commands, the - VNF owner will be asked to upload either an xml file (for Netconf) or - a JSON file (for Chef or Ansible). This file contains the parameter - values in a valid schema that would be sent to either the VNF or the - Chef/Ansible server to execute the action. For more detail on - Netconf, Chef, or Ansible, see the ONAP vendor guidelines at: - - https://wiki.onap.org/pages/viewpage.action?pageId=1015852&preview=/1015849/1017888/VNF%20Management%20Requirements%20for%20OpenECOMP.pdf - -- The VNF related key identifiers (vnf-type, vnfc-type, - vnfc-function-code) that will be stored in A&AI have been defined. - -Onboarding Process Steps: -------------------------- - -1. Use the APPC CDT GUI to populate **reference data** - describing the VNF and action to be onboarded. - - - Select the VNF, action, and protocol to be on-boarded. - - - Describe the VM/VNFC components that comprise the VNF’s. APPC - will use this VM/VNFC data to update A&AI when configuring the VNF - at run time. - -2. Create a **template** from a “golden” configuration file. - - - Upload a “golden configuration” file (described later) into the APPC CDT GUI. - - - Manually edit the configuration file to associate parameter names - with instance-specific values you wish to parameterize (e.g., IP addresses). - - - This creates a template file, which will be used at run-time to - create the payload that APPC sends to the VNF or to Ansible/Chef. - - - Alternative: If the golden configuration changes, rather than - manually re-creating an updated template, you can *automatically* - create an updated template by **Merging** a current parameter - name-value pairs file with the new configuration file. APPC will - scan the new configuration file, and automatically replace values - with parameter names. - -3. Create a **parameter definition** file describing instance-specific - parameters in the template. - - - Once you have a template, use the **Synchronize Template Parameters** button to - automatically create/update a parameter definition file (and a - parameter name-value pair file) based on the template. - - - You can then populate/update the fields describing each parameter. - - - If the parameters will be populated from external systems (such as INSTAR), you can upload - a “key file” that automatically populates key fields used to retrieve - data from the external system. - - - If the parameters will be populated from A&AI, you can select the - rules and key fields used to retrieve data from A&AI. - - - The parameter definition file will be used at run time to - automatically obtain parameter values from external system, A&AI, or a user - input spreadsheet for insertion into the template. - -4. Create a **parameter name-value pair file** for those parameters. - - - Once you have a template, use the **Synchronize Template Parameters** button to - automatically create a parameter name-value pair file (and a - parameter definition file) based on the template. - - - The parameter name-value file serves as a guide for populating - instance-specific data into the user input spreadsheet used at run - time. The parameter name-value file can also be used to automatically - create a template via the **Merge** function as described in step 2. - - - You can also use the **Synchronize With Name Values** button to update the parameter definitions to match an existing parameter name-values pair file. - -5. **Test** the template in your test environment using the **TEST** function of APPC CDT - - - Use the **Save All to APP-C** button in the CDT GUI to save the - artifacts for your VNF to APPC. This makes the current version of artifacts available to both the APPC CDT and APPC Run Time. - - - Prepare a “user input” excel file on your PC and upload it to the APPC CDT. - - - **Execute** the onboarded action on the VNF. View test progress and test results. . - -The screen shots in following sections illustrate how to use the APPC CDT GUI for each step. - -Artifacts used for Onboarding: ------------------------------- - -For a given VNF, each action must be on-boarded separately. Actions can -be on-boarded in any order; it is not required that “Configure” be the first action onboarded. - -You will create 1 Reference Data file for each VNF, and a set of up to 3 -files for each action you are onboarding: - - 1. Template - 2. Parameter definition file (pd\_configure) - 3. Parameter name-value pair file (param\_configure) - -For example, onboarding the “vABC” VNF for 2 actions (Configure and -ConfigModify) may result in these 7 files: - - 1. reference\_AllAction\_vABC\_0.0.1V - 2. template\_Configure\_vABC\_0.0.1V - 3. pd\_Configure\_vABC\_0.0.1V - 4. param\_Configure\_vABC\_0.0.1V - 5. template\_ConfigModify\_vABC\_0.0.1V - 6. pd\_ConfigModify\_vABC\_0.0.1V - 7. param\_ConfigModify\_vABC\_0.0.1V - -A **Template** is required for the Ansible, Chef and Netconf protocols. - -The **Parameter Definition** and **Parameter Name-Value Pair** artifacts -are typically used with the Configure and ConfigModify templates and are -optional for templates of other actions. - -OpenStack and REST protocols do not use a template or parameter -definitions or name-value pairs. - -Using the APPC Controller Design Tool for VNF Onboarding -======================================================== - -Go to the APPC CDT GUI in the test environment using a Firefox browser. - -http://: - -- Where: - - = The server IP or host where CDT is deployed. - - = By default 8080 for a HEAT deployed CDT or 30289 for an OOM deplyed CDT. - -|image4| - -Clicking on “About Us” will display the current software version and who to contact for support. The contact information is configurable. What is display in diagram is just an example. - -|image5| - -Choose “My VNF’s”. - -If you have not used APPC CDT previously, you will be asked to -enter your user id. Your work will be stored under this user id. There -is no password required at this time. - -Note: If multiple self-service users will be working on a set of VNF’s, -it is suggested that you enter a group\_name rather than your user\_id. -This group name would be used by all users in the group so that all -users can view/edit the same set of artifacts. - -If you have previously used APPC CDT, you user id will -automatically be selected. - -|image6| - -The “My VNFs” GUI displays a list of the vnf-type/vnfc-types which are -stored under your userid in the APPC database. You can choose either -“Create New VNF” or “View/Edit” for one of your existing VNF’s. - -|image7| - -If you have not created any VNF artifacts in the current release of the -APPC CDT, you will see a screen like this; click “Create new -VNF” to begin. - -VNF artifacts created using earlier versions of the APPC CDT -can be uploaded and then edited/saved, as shown on later screens. You -should not have to re-create these VNF artifacts. - -|image8| - -If you choose to create a new VNF, you will see a pop-up box like this. - -|image9| - -Enter the VNF Type (and optional VNFC Type) and click next. (The optional VNFC check box is explained later) - -Alternatively, you can leave the VNF type blank and choose “PROCEED -ANYWAY” if you want to proceed to the Reference Data screen where you -can populate the VNF reference data by uploading an existing Reference -File or by manually entering it. - -You must populate the VNF field if uploading the existing file does not -populate it. - -Populate reference data describing the VNF and action to be onboarded ---------------------------------------------------------------------- - -|image10| - -|image11| - -|image12| - -|image13| - -|image14| - -Note 1: When downloading your work to APPC; the system will download -only the artifacts that have been updated in the current session. You -may not see all 4 artifacts unless you visit/edit the reference, -template, parameter and parameter definition screens. - -Note 2: When downloading files, the system will display a pop-up window -for each file, but the windows are all placed on top of each other. You -can drag the pop-up windows if you want to see them all at the same -time. - -| - - - -| - -When using the Mozilla Firefox browser, selecting “Download to PC will display a dialog box giving you a choice of opening or saving the files, and an option to “Do this automatically for files like this for now on”. Choosing “save” and checking this option is a convenient way to easily save multiple downloaded artifacts from APP-C to your PC - -|image15a| - -Note regarding VNFC Type -~~~~~~~~~~~~~~~~~~~~~~~~ - -There are a limited number of VNF’s that are identified by both VNF type and VNFC type. When adding a new VNF of this kind to APP-C, enter the VNF type and check the VNFC box in the pop-up window, and choose NEXT. - -Alternatively, you can leave the VNF type blank and choose “PROCEED ANYWAY” if you want to proceed to the Reference Data screen where you can populate the VNF reference data by uploading an existing Reference File or by manually entering it. - -|image15b| - -On the subsequent Reference screen, you must add the VNFC type(s). - -|image15c| - -Enter the new VNFC type and click ADD to add it to a drop-down list of VNFC types for this VNF. Repeat for each VNFC type you wish to add. - -|image15d| - -Choose the desired VNFC Type from the drop-down list of VNFC types. - -|image15e| - -In the VNFC section, you must re-enter the VNFC type to match what you previously selected. - -|image15f| - -Populate OpenStack actions for a VM -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -You can also onboard OpenStack commands for the VM level components of -the VNF - -Under ‘Action’, select “OpenStack Actions” and then under ‘Protocol’ -select “OpenStack”. - -You must populate the ‘VNF type’ if it is not already populated. - -|image16| - -Next, upload an excel file of VM capabilities for your VNF. The excel -must list OpenStack actions in the first column, and then have a column -for each VM type (i.e., VNFC Function Code) showing which actions are -applicable for that VM type, as shown Excel sample below: - -|imageA| - -APPC will import the data from the excel and display the results. - -|image17| - -The Template and Parameter Definition tabs do not apply to OpenStack -commands. - -**REFERENCE DATA SCREEN HELP** - -+--------------------------+------------------------------------------------------------------------------------------------------------------+ -| **Field/Object** | **Description** | -+==========================+==================================================================================================================+ -| **VNF Reference Data** | -+--------------------------+------------------------------------------------------------------------------------------------------------------+ -| Action | The action to be executed on the VNF, e.g., “CONFIGURE” (see table below). | -+--------------------------+------------------------------------------------------------------------------------------------------------------+ -| VNF Type | The name of the VNF, e.g. vDBE. | -+--------------------------+------------------------------------------------------------------------------------------------------------------+ -| VNFC Type | NA when describing a VNF; When describing a VNFC, enter the VNFC name e.g.,MSC, SSC, MMC, etc. | -+--------------------------+------------------------------------------------------------------------------------------------------------------+ -| Device Protocol | Choose desired protocol e.g., NETCONF-XML (see table below). | -+--------------------------+------------------------------------------------------------------------------------------------------------------+ -| Template | Will there be a template created for this VNF and action? Yes/No. | -+--------------------------+------------------------------------------------------------------------------------------------------------------+ -| User Name | Enter the user name used to configure the VNF e.g., “admin” or “root”. | -+--------------------------+------------------------------------------------------------------------------------------------------------------+ -| Port Number | Enter the port number used to configure the VNF, e.g., 22. | -+--------------------------+------------------------------------------------------------------------------------------------------------------+ -| Context URL | Enter the context portion of the REST URL (Currently used only for the HealthCheck action with REST protocol). | -+--------------------------+------------------------------------------------------------------------------------------------------------------+ -| **VNFC information** | -+--------------------------+------------------------------------------------------------------------------------------------------------------+ -| VNFC Type | Enter the VNFC name e.g. MSC, SSC, MMC, etc. | -+--------------------------+------------------------------------------------------------------------------------------------------------------+ -| VNFC Function Code | Enter the standard 3 character value for the VNFC. | -+--------------------------+------------------------------------------------------------------------------------------------------------------+ -| IP Address V4 OAM VIP | Select Y to store the O&AM VIP address with the VNFC record; otherwise select N. | -+--------------------------+------------------------------------------------------------------------------------------------------------------+ -| Group Notation Type | Select the naming scheme for VNFC/VM instances (first-vnfc-name, fixed value, relative value) | -+--------------------------+------------------------------------------------------------------------------------------------------------------+ -| Group Notation Value | For first-vnfc-name type, enter text such as “pair” or “group”. | -| | | -| | For fixed value type, enter any alpha-numeric text “1”, “test” etc. | -| | | -| | For relative value type, enter a number “1”, “2”, “4”, etc | -+--------------------------+------------------------------------------------------------------------------------------------------------------+ -| Number of VM’s | Enter the # of VM’s for this VNFC. | -+--------------------------+------------------------------------------------------------------------------------------------------------------+ - -| - -This table shows which actions and protocols are currently available for -on-boarding with the Beijing release. - -+----------------------------------------+---------------+---------------+------------+------------+----------------+---------------+ -| **Action** |**Netconf-XML**| **Ansible** | **Chef** | **REST** | **OpenStack** |**Protocol is**| -| |**Restconf** | | | | **(VM Level)** |**Not** | -| | | | | | |**Applicable** | -+========================================+===============+===============+============+============+================+===============+ -| **ActionStatus** |   |   |   |   | | NA | -+----------------------------------------+---------------+---------------+------------+------------+----------------+---------------+ -| **AttachVolume** |   |   |   |   | YES | | -+----------------------------------------+---------------+---------------+------------+------------+----------------+---------------+ -| **Audit** | YES  | YES  | YES | YES  | | | -+----------------------------------------+---------------+---------------+------------+------------+----------------+---------------+ -| **CheckLock** | | | |   | | NA | -+----------------------------------------+---------------+---------------+------------+------------+----------------+---------------+ -| **Configure** | YES | YES | YES |   |   | | -+----------------------------------------+---------------+---------------+------------+------------+----------------+---------------+ -| **Config Modify** | YES | YES | YES |   |   | | -+----------------------------------------+---------------+---------------+------------+------------+----------------+---------------+ -| **Config Backup** |   | YES | YES |   |   | | -+----------------------------------------+---------------+---------------+------------+------------+----------------+---------------+ -| **Config Restore** |   | YES | YES |   |   | | -+----------------------------------------+---------------+---------------+------------+------------+----------------+---------------+ -| **ConfigScaleOut** | YES   | YES | YES |   |   | | -+----------------------------------------+---------------+---------------+------------+------------+----------------+---------------+ -| **DetachVolume** |   |   |   |   | YES | | -+----------------------------------------+---------------+---------------+------------+------------+----------------+---------------+ -| **DistributeTraffic** |   | YES   | YES   |   | | | -+----------------------------------------+---------------+---------------+------------+------------+----------------+---------------+ -| **DistributeTrafficCheck** |   | YES   | YES   |   | | | -+----------------------------------------+---------------+---------------+------------+------------+----------------+---------------+ -| **Evacuate** |   |   |   |   | YES | | -+----------------------------------------+---------------+---------------+------------+------------+----------------+---------------+ -| **HealthCheck** |   | YES | YES | YES |   | | -+----------------------------------------+---------------+---------------+------------+------------+----------------+---------------+ -| **Lock** |   | | | |   | NA | -+----------------------------------------+---------------+---------------+------------+------------+----------------+---------------+ -| **Migrate** |   |   |   |   | YES | | -+----------------------------------------+---------------+---------------+------------+------------+----------------+---------------+ -| **QuiesceTraffic** |   | YES | YES |   |   | | -+----------------------------------------+---------------+---------------+------------+------------+----------------+---------------+ -| **Rebuild** |   |   |   |   | YES | | -+----------------------------------------+---------------+---------------+------------+------------+----------------+---------------+ -| **Restart** |   |   |   |   | YES | | -+----------------------------------------+---------------+---------------+------------+------------+----------------+---------------+ -| **ResumeTraffic** |   | YES | YES |   |   | | -+----------------------------------------+---------------+---------------+------------+------------+----------------+---------------+ -| **Snapshot** |   |   |   |   | YES | | -+----------------------------------------+---------------+---------------+------------+------------+----------------+---------------+ -| **Start** |   |   |   |   | YES | | -+----------------------------------------+---------------+---------------+------------+------------+----------------+---------------+ -| **Start Application** |   | YES | YES |   |   | | -+----------------------------------------+---------------+---------------+------------+------------+----------------+---------------+ -| **Stop** |   |   |   |   | YES | | -+----------------------------------------+---------------+---------------+------------+------------+----------------+---------------+ -| **Stop Application** |   | YES | YES |   |   | | -+----------------------------------------+---------------+---------------+------------+------------+----------------+---------------+ -| **Sync** | YES  | YES  | YES  |  YES | | | -+----------------------------------------+---------------+---------------+------------+------------+----------------+---------------+ -| **Unlock** |   |   |   |   | | NA | -+----------------------------------------+---------------+---------------+------------+------------+----------------+---------------+ -| **UpgradeBackout** |   | YES | YES |   |   | | -+----------------------------------------+---------------+---------------+------------+------------+----------------+---------------+ -| **UpgradeBackup** |   | YES | YES |   |   | | -+----------------------------------------+---------------+---------------+------------+------------+----------------+---------------+ -| **UpgradePostCheck** |   | YES | YES |   |   | | -+----------------------------------------+---------------+---------------+------------+------------+----------------+---------------+ -| **UpgradePreCheck** |   | YES | YES |   |   | | -+----------------------------------------+---------------+---------------+------------+------------+----------------+---------------+ -| **UpgradeSoftware** |   | YES | YES |   |   | | -+----------------------------------------+---------------+---------------+------------+------------+----------------+---------------+ - - - -Create a template from a “golden” configuration file ----------------------------------------------------- - -There are several ways to create a template in APPC CDT: - -- Start from golden instance config file; manually add parameters - (described in this section) - -- Start with a template file, manually add more parameters. (described - in section Synchronizing a Template) - -- Start with config file; create updated template by **merging** - name-value pairs. (described in Create a file containing name-value pairs for parameters section) - -Start with a working configuration for a “golden instance” of the VNF -(xml if Netconf) or the payload to be downloaded to the Chef or Ansible -server (JSON). - -Open the XML or JSON file in Notepad ++ and verify that the format is -schema compliant. If the xml file is for a post-instantiation -configuration, then modify the config to include only statements that -are to be added (merged) with any configuration that is on the VNF -instance after instantiation. For example, remove statements that might -change root passwords, etc. - -Optionally, add Velocity statements to the file, if desired, to handle -special constructs such as variable lists, template defined constants, -conditional statements, etc. - -Here are links with more information about the Velocity java-based -template engine: - - http://velocity.apache.org/engine/2.0/vtl-reference.html - - http://velocity.apache.org/engine/2.0/user-guide.html - -This screen shows a sample Golden Configuration file that has been -uploaded to APP-C CDT. - -|image18| - -Next, designate instance-specific values as parameters, using this -procedure: - - 1) Highlight the instance-specific value (such as “node0 ) with the cursor and then type “CTRL” and “4” - - |image19| - - 2) Type the name you want to use for this parameter into the pop-up window and click SUBMIT - - |image20| - - 3) The system will display your parameter name after the value you highlighted - - |image21| - - 4) Repeat for each instance-specific value that you wish to turn into a parameter. - -*Summary of editing commands:* - - - CTRL+4 to add a parameter (also saves previous unsaved parameter) - - CTRL+S to save a parameter - - CTRL+Z to undo the last edit - -Notes on naming Parameters: - -- Choose meaningful, unique parameter names for each parameter. If the - same parameter value appears in multiple places in the config, the - parameter name which is assigned to the first instance will be - automatically assigned to all instances. However, you may choose a - different parameter name for each instance of the parameter value - (except when using the MERGE function). - -- Use only dash (-) or underline (\_) as separators between words in - the name. - -- The name should not contain spaces or any other special characters. - -- Do not use parameter names which are sub-strings of other parameter - names. For example, don’t use field1 and field12 as parameter names. - -In the template, the first instance of a parameter will be highlighted in green and subsequent instances of the same parameter will be highlighted in orange. - -Synchronizing a Template -~~~~~~~~~~~~~~~~~~~~~~~~ - -Once you have named all the parameters (this example shows 3 -parameters), click the “SYNCHRONIZE TEMPLATE PARAMETERS” button to automatically create a -parameter definition file and a parameter name-value file. The next -sections describe these files. - -It may take a few seconds for the system to synchronize; when it is -complete, you will be taken to the Parameter Definition screen. - -Remember to use the SAVE and/or DOWNLOAD buttons on the Reference Data -screen to preserve your work. - -|image23| - -Modifying an Existing Template -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -In addition to creating new templates, you can also modify an existing -template by adding or removing parameter names. - -To add a new parameter name, follow the steps in the Create a template from a "golden" configuration file section above. -SYNCHRONIZE TEMPLATE PARAMETERS to add the new parameter to the name/value and parameter -definition GUI. - -To remove an existing parameter name, remove the parameter name (i.e., -${name}) using the backspace key and replace with the static value. Then -SYNCHRONIZE TEMPLATE PARAMETERS to remove the parameter from the name/value and parameter -definition GUI. - -If the available template has parameter names (as opposed to the golden configuration/ base config typically shared by VNF owners), you can upload that template and manually add the braces around the parameter names. Then click on SYNCHRONIZE TEMPLATE PARAMETERS to generate the PD file with source as Manual. - -Remember to use the SAVE and/or DOWNLOAD buttons on the Reference Data -screen to preserve your work. - -Create a parameter definition file describing instance-specific parameters in the template ------------------------------------------------------------------------------------------- - -Clicking the “SYNCHRONIZE TEMPLATE PARAMETERS” button after creating a template will automatically create/update a parameter definition file for -that template (and a parameter name-value file described in the next -section). Alternatively, you can upload an existing parameter definition -file from your PC. - -You can view or edit the definition fields for each parameter via the -Parameter Definition screen. Note that any edits to the parameter names -would be overwritten by a subsequent SYNCHRONIZE TEMPLATE PARAMETERS. - -|image24| - -Select a Source for each parameter -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -There are three choices for the source: - -1. **External Systems**. APPC will automatically obtain parameter values from - an external system (typically IP addresses for VNF’s). First, obtain a - “key file” for your VNF. Then use the - “Upload Key File” button on the Parameter Definition screen. APPC - will automatically populate key names and values used to retrieve data - from an external system. - - -2. **A&AI**. APPC will automatically obtain parameter values from - A&AI (typically VNF/VNFC/VM identifiers). After selecting “A&AI”, - select a rule type and APPC will automatically populate the key - names and values. For rule types that include a list, populate the - ‘Filter By Field’ and ‘Filter By Value’. - - |image26| - -3. **Manual**. APPC will use a manually-created excel to populate - parameter values. Later section describes this User Input Spreadsheet. - -Remember to use the SAVE and/or DOWNLOAD buttons on the Reference Data -screen to preserve your work. - -Create a file containing name-value pairs for parameters --------------------------------------------------------- - -Clicking the “SYNCHRONIZE TEMPLATE PARAMETERS” button after creating a template (see section -Synchronizing a Template) will automatically create/update a parameter name-value pair file -for that template (and a parameter definition file described in the -previous section). - -Navigate to the Template tab and “Param Values” subtab to view/edit -parameter name-value pairs. - -If you make any edits, remember to use the SAVE and/or DOWNLOAD buttons -on the Reference Data screen to preserve your work. - -|image27| - -Option: Using MERGE to automatically create a template from a parameter name-value pair file -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -APPC CDT also provides a way to create a template from an -existing parameter name-value pair file. This is useful when the -configuration of the VNF has changed. Rather than manually recreating -the template, you can use the MERGE function to automatically add -parameter names based on a valid name-value pairs file from a previous -template. - -First, navigate to the Template tab and “Param Values” subtab and click -on UPLOAD PARAM FILE - -|image28| - -Then navigate to the Template configuration screen. Upload a -configuration file that contains values you wish to turn into -parameters. - -|image29| - -Next, click “MERGE FROM PARAM”. APPC will automatically associate the parameter values in the uploaded configuration with parameter names from the parameter name/value. If duplicate parameter values are found in the configuration, APP-C will highlight the duplicate value & name in orange and let the user edit the parameter name. When the duplicate parameter name has been successfully replaced with a unique name, the highlight will change from orange to green.. - -After using the MERGE FROM PARAM button to create a template, you can use the -SYNCHRONIZE TEMPLATE PARAMETERS button to create/update the parameter definition file and -name-value files. - -Remember to use the SAVE and/or DOWNLOAD buttons on the Reference Data -screen to preserve your work. - -|image30| - - -Option: Synchronize with Name/Values -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -There may be a scenario where you have created or uploaded a template, and SYNCHONIZED TEMPLATE PARAMETERS, and then you want to remove some name-value pairs. APPC provides a SYNCHRONIZE WITH NAME VALUES button that will automatically synchronize the parameter definitions with your updated name value pairs. - - - - Step 1: Create or upload template - - - Step 2: SYNCHRONIZE TEMPLATE PARAMETERS. (APPC will update Parameter Definition file and Name-Value Pair file to match Template.) - - - Step 3: Manually edit Name-Value Pair file (or upload a changed Name-Value Pair file) - - - Step 4: SYNCHRONIZE WITH NAME VALUES. (see screen shot below)(APPC will update Parameter Definition file to match Name-Value Pair file.) - - - Step 5: Examine Parameter Definitions to confirm they now match updated Name-Value Pair file. - - -|image30a| - - -Test the template in a lab using APPC CDT Test Function -======================================================= - -The APPC CDT **TEST** action is used to initiate configuration -and other lifecycle commands - -**Prerequisites:** - - A. Testing requires an instance of the target VNF to be reachable from your test environment. - - B. You have created the on-boarding artifacts (e.g., reference file, template, etc) for the target VNF type and action in CDT and saved them to APPC. - - C. You have created a user input spreadsheet for the VNF and action you wish to test. - -**Steps to Test a template:** - - 1. Choose the TEST function on the APPC CDT home page - - 2. Upload the user input spreadsheet - - 3. Click on EXECUTE TEST - - 4. View test progress; poll for test status if necessary. - - 5. View Test Results - - -User Input Spreadsheet ----------------------- - -The following steps are used to prepare a user input spreadsheet for the -VNF instance and action to be tested. - -1. Start with this generic user input excel spreadsheet. - - :download:`Generic 1802 User Input Spreadsheet v.02.xlsx` (compatible with excel 2013) - - Update the user-input sections of the spreadsheet. - - - a) Upload Data tab: choose action, populate VNF-ID - - - b) >Action< tab: Select the tab for the action being tested. Choose a protocol and enter required action identifiers & request parameter values. Enter any payload parameter names and values required for this associated template. (copy/paste from a name-value pair file or other source). - - The screen shots on the following pages show the user input sections highlighted in yellow. - -2. Save the spreadsheet with a name for your VNF instance and action. - -“Upload Data” tab – Select action to be tested and populate any action -identifiers such as vnf-id. - -|image31| - -Action tab: This example is for the ConfigModify action, so the -“ConfigModify” tab is shown. Choose a protocol and enter required action -identifiers & request parameter values. Enter any payload parameter -names and values required for this associated template. (You may -copy/paste from a name-value pair file or other source). - -|image32| - -Using APPC CDT TEST Function ----------------------------- - -**Steps to use the “TEST” function of the APPC Design Tool** - -1. Choose the TEST function on the APPC Design Tool home page - - |image33| - -2. Upload the user input spreadsheet -3. Click on EXECUTE TEST -4. View test progress; poll for test status if necessary. - - |image34| - - |image35| - -5. View Test Results - - |image36| - - -Note on populating southbound properties: -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -When a new vnf-type is created or a new action is added to an existing -vnf-type using the CDT tool and the Reference Data artifact is loaded to -APPC, an update is made to the APPC run-time southbound properties -file for the vnf-type.   The southbound properties are needed for -connecting to a VNF instance or Ansible server.  The southbound -properties contain the following information: - -``{vnf\_type}.{protocol}.{action}.user = {value}`` - -``{vnf\_type}.{protocol}.{action}.port = {value}`` - -``{vnf\_type}.{protocol}.{action}.password = {value}`` - -``{vnf\_type}.{protocol}.{action}.url = {value}`` - -The user, port, and url values are contained in the Reference Data -artifact, if populated by the self-service user.  - -The current process that creates the southbound properties from the Reference Data only updates the southbound properties file on a single APPC node in the ODL cluster..   - - -APP-C Design Tool - File Descriptions -===================================== - -+--------------------------------------------------------------------------------------------------------------------------------------+-------------------+ -| **File Description** | **File Format** | -+======================================================================================================================================+===================+ -| | | -| **Pre-template Config file** –contains a ‘golden’ or working configuration (for Netconf) or JSON data block (for Chef or Ansible). | XML, JSON | -| | | -+--------------------------------------------------------------------------------------------------------------------------------------+-------------------+ -| | | -| **Reference file** – describes a VNF in terms of its subtending VM’s and VNFC’s and the actions/protocols being onboarded. | XML, JSON | -| | | -+--------------------------------------------------------------------------------------------------------------------------------------+-------------------+ -| | | -| **Template file** – a configuration file with parameters for instance-specific fields. | XML | -| | | -+--------------------------------------------------------------------------------------------------------------------------------------+-------------------+ -| | | -| **Parameter Definition file** (aka pd\_Configure) contains **parameter definitions** associated with a template. | YAML | -| | | -+--------------------------------------------------------------------------------------------------------------------------------------+-------------------+ -| | | -| **Name-Value file** (aka param\_Configure) contains name-value pairs for parameters associated with a template. | JSON | -| | | -+--------------------------------------------------------------------------------------------------------------------------------------+-------------------+ -| | | -| **Key data file** – contains external system data to populate a PD configure file. | TXT | -| | | -+--------------------------------------------------------------------------------------------------------------------------------------+-------------------+ - -The ADMIN Configuration GUI -=========================== - -The Design Tool provide a user interface to onboard configuration -servers that App-C interacts with. Initially the Admin Configuration GUI -supports only Ansible servers. The Admin GUI is accessible to users -providing the following functionality. - -- Display all existing configuration server profiles on the default - screen - -- Adding new server profiles - -- Editing existing server profiles - -- Sort user profiles on the display list - - 1. Admin Tab - -On Design Tool’s Home screen has the ADMIN menu item along with the -others. If the user has the privilege to access the Admin GUI, the ADMIN -menu item is enabled. - -|image37| - -Admin Default Screen --------------------- - -The Admin default screen displays the existing configuration server -profiles. - -|image38| - -**Data fields**: - -- Configuration Server URL - - This is the URL of the Ansible server. App-C uses this information to - establish connectivity to the Ansible server. Network routes and - firewall configuration should be completed prior to App-C - communicating with the server. - -- Cloud-owner/Cloud-Region/Tenant - - During runtime, App-C selects an Ansible server to configure a VNF by - matching on the VNF’s Tenant-ID. A Tenant-ID is unique with a - Cloud-Owner and Cloud-Region. This information must be the same as - stored in A&AI. - -- Description - - This a free text field for entering information identifying the - Ansible server. - -- Modifier - - The user ID last modified this profile. - -- Date Modified - - The timestamp of this profile was last modified. - -**Button functionality**: - -- CREATE NEW SERVER - - To create a new configuration server profile - -- VIEW/EDIT - - To view or edit an existing server profile - -- DOWNLOAD ALL TO PC - - Download load Admin Artifact to PC - -- SAVE ALL TO APPC - - Save Admin Artifact to App-C database - -- Sorting columns - - Clicking on the triangles symbol next to a column heading would sort - the profiles by that column. Subsequent clicking would toggle the - sorting between ascending and descending order. - -|image39|\ Creating a New Servers Profile ------------------------------------------ - -The Server Profiles screen allows user to add server profiles. During -server profile creation, the Modifier and Date Modified parameters are -empty. - -|image40| - -**Data fields**: - -- Configuration Server URL - - Enter the URL of the Ansible server or server cluster. - - Example: http://ansible.appc.onap.org:5000 - -- Cloud-owner/Cloud-Region/Tenant - - For each Ansible server, there must be at least one tenant entry. A - cloud-owner, cloud-region-id, and tenant-id combination determines a - unique tenant. - -- Description - - Enter any information into this Description field. - -- Creator and Date Created fields are pre-populated and not user - editable. - -- Modifier and Date Modified are empty on the new profile screen - -**Button functionality**: - -ADD button: add the entered Cloud-owner, Cloud-Region-ID, and Tenant-ID -as new tenant entry - -CANCEL Button: discard the changes and return to Admin home screen. - -RETURN button: return back to the Admin home screen. Data is not saved -database as this point. - -|image41|\ Note: Remember to use the “SAVE ALL TO APPC” button on the -Admin home screen to preserve your work. - -Editing an Existing Server Profile ----------------------------------- - - The Configuration Server screen allows user to edit existing Ansible - profiles. CDT retrieves the server’s profile from database for - editing. - -**Data fields**: - -- Configuration Server URL - - URL of the Ansible server or server cluster. - - Example: http://ansible.appc.onap.org:5000 - - Cloud-owner, Cloud-Region-ID, Tenant ID - - For each Ansible server, there must be at least one tenant entry. A - cloud-owner, cloud-region-id, and tenant-id combination determines a - unique tenant. - -- Description - - Enter any information into this Description field. - -- Creator, Date Created, Modifier, and Date Modified fields are - pre-populated and not user editable. - -**Button functionality**: - -ADD button: add the entered Cloud-owner, Cloud-Region-ID, and Tenant-ID -as new tenant entry - -REMOVE button: removes a tenant entry - -CANCEL Button: discard the changes and return to Admin home screen. - -RETURN button: return back to the Admin home screen. Data is not saved -database as this point. - -|image41|\ Note: Remember to use the “SAVE ALL TO APPC” button on the -Admin home screen to preserve your work. - -|image42| - -Sorting Server Profiles ------------------------ - - Design Tool provides a sorting capability similar to the VNF profile - screen. - -- User can select columns to be sorted by clicking on the triangle - symbols next to the column headings. - -- Repeated clicking on an arrow symbol toggles the sorting orders - between ascending and descending. - - -.. |image0| image:: media/image0.png - :width: 7.88889in - :height: 4.43750in -.. |image1| image:: media/image1.png - :width: 8.72292in - :height: 4.51788in -.. |image2| image:: media/image2.png - :width: 8.75000in - :height: 4.58908in -.. |image3| image:: media/image3.png - :width: 8.70833in - :height: 4.89844in -.. |image4| image:: media/image4.png - :width: 7.46875in - :height: 4.19310in -.. |image5| image:: media/image5.png - :width: 7.23958in - :height: 3.87172in -.. |image6| image:: media/image6.png - :width: 7.58491in - :height: 4.26651in -.. |image7| image:: media/image7.png - :width: 9.43750in - :height: 5.30859in -.. |image8| image:: media/image8.png - :width: 7.86980in - :height: 4.72917in -.. |image9| image:: media/image9.png - :width: 7.56250in - :height: 4.54450in -.. |image10| image:: media/image10.png - :width: 9.01042in - :height: 5.06836in -.. |image11| image:: media/image11.png - :width: 9.44792in - :height: 5.31445in -.. |image12| image:: media/image12.png - :width: 9.48958in - :height: 5.33789in -.. |image13| image:: media/image13.png - :width: 9.48125in - :height: 5.33320in -.. |image14| image:: media/image14.png - :width: 9.25926in - :height: 5.20833in -.. |image15| image:: media/image15.png - :width: 9.05556in - :height: 5.09375in -.. |image15a| image:: media/image15a.png -.. |image15b| image:: media/image15b.png -.. |image15c| image:: media/image15c.png -.. |image15d| image:: media/image15d.png -.. |image15e| image:: media/image15e.png -.. |image15f| image:: media/image15f.png -.. |image16| image:: media/image16.png - :width: 5.79167in - :height: 3.74135in -.. |imageA| image:: media/imageA.png - :width: 5.79167in - :height: 3.74135in -.. |image17| image:: media/image17.png - :width: 6.13542in - :height: 4.97745in -.. |image18| image:: media/image18.png - :width: 9.00000in - :height: 5.27639in -.. |image19| image:: media/image19.png - :width: 5.43423in - :height: 1.83333in -.. |image20| image:: media/image20.png - :width: 5.44473in - :height: 1.93750in -.. |image21| image:: media/image21.png - :width: 5.32292in - :height: 1.92771in -.. |image23| image:: media/image23.png - :width: 7.54167in - :height: 4.24219in -.. |image24| image:: media/image24.png - :width: 7.48148in - :height: 4.20833in -.. |image26| image:: media/image26.png - :width: 6.87789in - :height: 3.78125in -.. |image27| image:: media/image27.png - :width: 7.97170in - :height: 4.48408in -.. |image28| image:: media/image28.png - :width: 8.56604in - :height: 4.81840in -.. |image29| image:: media/image29.png - :width: 9.00943in - :height: 5.06781in -.. |image30| image:: media/image30.png - :width: 8.07407in - :height: 4.54167in -.. |image30a| image:: media/image30a.png -.. |image31| image:: media/image31.png - :width: 9.00000in - :height: 5.18958in -.. |image32| image:: media/image32.png - :width: 9.00000in - :height: 5.18958in -.. |image33| image:: media/image33.png - :width: 9.00000in - :height: 5.18958in -.. |image34| image:: media/image34.png - :width: 9.00000in - :height: 5.18958in -.. |image35| image:: media/image35.png - :width: 9.00000in - :height: 5.18958in -.. |image36| image:: media/image36.png - :width: 9.00000in - :height: 5.18958in -.. |image37| image:: media/image37.png - :width: 5.83681in - :height: 0.41095in -.. |image38| image:: media/image38.png - :width: 6.5in - :height: 1.87361in -.. |image39| image:: media/image39.png -.. |image40| image:: media/image40.png - :width: 6.656in - :height: 2.20018in -.. |image41| image:: media/image41.png - :width: 0.21528in - :height: 0.21528in -.. |image42| image:: media/image42.png - :width: 6.5in - :height: 3.05139in - - diff --git a/docs/APPC CDT Guide/Generic 1802 User Input Spreadsheet v.02.xlsx b/docs/APPC CDT Guide/Generic 1802 User Input Spreadsheet v.02.xlsx deleted file mode 100644 index 716b69674..000000000 Binary files a/docs/APPC CDT Guide/Generic 1802 User Input Spreadsheet v.02.xlsx and /dev/null differ diff --git a/docs/APPC CDT Guide/media/image0.png b/docs/APPC CDT Guide/media/image0.png deleted file mode 100644 index 04770cc0f..000000000 Binary files a/docs/APPC CDT Guide/media/image0.png and /dev/null differ diff --git a/docs/APPC CDT Guide/media/image1.png b/docs/APPC CDT Guide/media/image1.png deleted file mode 100644 index 9938985fe..000000000 Binary files a/docs/APPC CDT Guide/media/image1.png and /dev/null differ diff --git a/docs/APPC CDT Guide/media/image10.png b/docs/APPC CDT Guide/media/image10.png deleted file mode 100644 index 9851fce63..000000000 Binary files a/docs/APPC CDT Guide/media/image10.png and /dev/null differ diff --git a/docs/APPC CDT Guide/media/image11.png b/docs/APPC CDT Guide/media/image11.png deleted file mode 100644 index de40534d2..000000000 Binary files a/docs/APPC CDT Guide/media/image11.png and /dev/null differ diff --git a/docs/APPC CDT Guide/media/image12.png b/docs/APPC CDT Guide/media/image12.png deleted file mode 100644 index c0106c0aa..000000000 Binary files a/docs/APPC CDT Guide/media/image12.png and /dev/null differ diff --git a/docs/APPC CDT Guide/media/image13.png b/docs/APPC CDT Guide/media/image13.png deleted file mode 100644 index fe449376b..000000000 Binary files a/docs/APPC CDT Guide/media/image13.png and /dev/null differ diff --git a/docs/APPC CDT Guide/media/image14.png b/docs/APPC CDT Guide/media/image14.png deleted file mode 100644 index fb3382182..000000000 Binary files a/docs/APPC CDT Guide/media/image14.png and /dev/null differ diff --git a/docs/APPC CDT Guide/media/image15.png b/docs/APPC CDT Guide/media/image15.png deleted file mode 100644 index 0c70ae321..000000000 Binary files a/docs/APPC CDT Guide/media/image15.png and /dev/null differ diff --git a/docs/APPC CDT Guide/media/image15a.png b/docs/APPC CDT Guide/media/image15a.png deleted file mode 100644 index f0057d855..000000000 Binary files a/docs/APPC CDT Guide/media/image15a.png and /dev/null differ diff --git a/docs/APPC CDT Guide/media/image15b.png b/docs/APPC CDT Guide/media/image15b.png deleted file mode 100644 index af3f0d87e..000000000 Binary files a/docs/APPC CDT Guide/media/image15b.png and /dev/null differ diff --git a/docs/APPC CDT Guide/media/image15c.png b/docs/APPC CDT Guide/media/image15c.png deleted file mode 100644 index a22968bcb..000000000 Binary files a/docs/APPC CDT Guide/media/image15c.png and /dev/null differ diff --git a/docs/APPC CDT Guide/media/image15d.png b/docs/APPC CDT Guide/media/image15d.png deleted file mode 100644 index 44b9d41d3..000000000 Binary files a/docs/APPC CDT Guide/media/image15d.png and /dev/null differ diff --git a/docs/APPC CDT Guide/media/image15e.png b/docs/APPC CDT Guide/media/image15e.png deleted file mode 100644 index ff3e9b38d..000000000 Binary files a/docs/APPC CDT Guide/media/image15e.png and /dev/null differ diff --git a/docs/APPC CDT Guide/media/image15f.png b/docs/APPC CDT Guide/media/image15f.png deleted file mode 100644 index ccd62db43..000000000 Binary files a/docs/APPC CDT Guide/media/image15f.png and /dev/null differ diff --git a/docs/APPC CDT Guide/media/image16.png b/docs/APPC CDT Guide/media/image16.png deleted file mode 100644 index c858ab3fc..000000000 Binary files a/docs/APPC CDT Guide/media/image16.png and /dev/null differ diff --git a/docs/APPC CDT Guide/media/image17.png b/docs/APPC CDT Guide/media/image17.png deleted file mode 100644 index 1f949d36a..000000000 Binary files a/docs/APPC CDT Guide/media/image17.png and /dev/null differ diff --git a/docs/APPC CDT Guide/media/image18.png b/docs/APPC CDT Guide/media/image18.png deleted file mode 100644 index f592fe8f2..000000000 Binary files a/docs/APPC CDT Guide/media/image18.png and /dev/null differ diff --git a/docs/APPC CDT Guide/media/image19.png b/docs/APPC CDT Guide/media/image19.png deleted file mode 100644 index 4893af5da..000000000 Binary files a/docs/APPC CDT Guide/media/image19.png and /dev/null differ diff --git a/docs/APPC CDT Guide/media/image2.png b/docs/APPC CDT Guide/media/image2.png deleted file mode 100644 index ca5e67dc0..000000000 Binary files a/docs/APPC CDT Guide/media/image2.png and /dev/null differ diff --git a/docs/APPC CDT Guide/media/image20.png b/docs/APPC CDT Guide/media/image20.png deleted file mode 100644 index 8a627da33..000000000 Binary files a/docs/APPC CDT Guide/media/image20.png and /dev/null differ diff --git a/docs/APPC CDT Guide/media/image21.png b/docs/APPC CDT Guide/media/image21.png deleted file mode 100644 index 5e8b8985a..000000000 Binary files a/docs/APPC CDT Guide/media/image21.png and /dev/null differ diff --git a/docs/APPC CDT Guide/media/image23.png b/docs/APPC CDT Guide/media/image23.png deleted file mode 100644 index 4bcaaa701..000000000 Binary files a/docs/APPC CDT Guide/media/image23.png and /dev/null differ diff --git a/docs/APPC CDT Guide/media/image24.png b/docs/APPC CDT Guide/media/image24.png deleted file mode 100644 index 680ff38f2..000000000 Binary files a/docs/APPC CDT Guide/media/image24.png and /dev/null differ diff --git a/docs/APPC CDT Guide/media/image26.png b/docs/APPC CDT Guide/media/image26.png deleted file mode 100644 index d9e9e4807..000000000 Binary files a/docs/APPC CDT Guide/media/image26.png and /dev/null differ diff --git a/docs/APPC CDT Guide/media/image27.png b/docs/APPC CDT Guide/media/image27.png deleted file mode 100644 index 2da4784e8..000000000 Binary files a/docs/APPC CDT Guide/media/image27.png and /dev/null differ diff --git a/docs/APPC CDT Guide/media/image28.png b/docs/APPC CDT Guide/media/image28.png deleted file mode 100644 index 9f84129b3..000000000 Binary files a/docs/APPC CDT Guide/media/image28.png and /dev/null differ diff --git a/docs/APPC CDT Guide/media/image29.png b/docs/APPC CDT Guide/media/image29.png deleted file mode 100644 index 4a38cd823..000000000 Binary files a/docs/APPC CDT Guide/media/image29.png and /dev/null differ diff --git a/docs/APPC CDT Guide/media/image3.png b/docs/APPC CDT Guide/media/image3.png deleted file mode 100644 index ac1c9becd..000000000 Binary files a/docs/APPC CDT Guide/media/image3.png and /dev/null differ diff --git a/docs/APPC CDT Guide/media/image30.png b/docs/APPC CDT Guide/media/image30.png deleted file mode 100644 index 320511868..000000000 Binary files a/docs/APPC CDT Guide/media/image30.png and /dev/null differ diff --git a/docs/APPC CDT Guide/media/image30a.png b/docs/APPC CDT Guide/media/image30a.png deleted file mode 100644 index 24b43392b..000000000 Binary files a/docs/APPC CDT Guide/media/image30a.png and /dev/null differ diff --git a/docs/APPC CDT Guide/media/image31.png b/docs/APPC CDT Guide/media/image31.png deleted file mode 100644 index 3ff322e8a..000000000 Binary files a/docs/APPC CDT Guide/media/image31.png and /dev/null differ diff --git a/docs/APPC CDT Guide/media/image32.png b/docs/APPC CDT Guide/media/image32.png deleted file mode 100644 index 1d6d58159..000000000 Binary files a/docs/APPC CDT Guide/media/image32.png and /dev/null differ diff --git a/docs/APPC CDT Guide/media/image33.png b/docs/APPC CDT Guide/media/image33.png deleted file mode 100644 index cacc1b876..000000000 Binary files a/docs/APPC CDT Guide/media/image33.png and /dev/null differ diff --git a/docs/APPC CDT Guide/media/image34.png b/docs/APPC CDT Guide/media/image34.png deleted file mode 100644 index ef4811524..000000000 Binary files a/docs/APPC CDT Guide/media/image34.png and /dev/null differ diff --git a/docs/APPC CDT Guide/media/image35.png b/docs/APPC CDT Guide/media/image35.png deleted file mode 100644 index 7c546b6b8..000000000 Binary files a/docs/APPC CDT Guide/media/image35.png and /dev/null differ diff --git a/docs/APPC CDT Guide/media/image36.png b/docs/APPC CDT Guide/media/image36.png deleted file mode 100644 index 89bebc805..000000000 Binary files a/docs/APPC CDT Guide/media/image36.png and /dev/null differ diff --git a/docs/APPC CDT Guide/media/image37.png b/docs/APPC CDT Guide/media/image37.png deleted file mode 100644 index e7278fdcf..000000000 Binary files a/docs/APPC CDT Guide/media/image37.png and /dev/null differ diff --git a/docs/APPC CDT Guide/media/image38.png b/docs/APPC CDT Guide/media/image38.png deleted file mode 100644 index 3e9763b44..000000000 Binary files a/docs/APPC CDT Guide/media/image38.png and /dev/null differ diff --git a/docs/APPC CDT Guide/media/image39.png b/docs/APPC CDT Guide/media/image39.png deleted file mode 100644 index 4ecb1cbd4..000000000 Binary files a/docs/APPC CDT Guide/media/image39.png and /dev/null differ diff --git a/docs/APPC CDT Guide/media/image4.png b/docs/APPC CDT Guide/media/image4.png deleted file mode 100644 index 99e60a28d..000000000 Binary files a/docs/APPC CDT Guide/media/image4.png and /dev/null differ diff --git a/docs/APPC CDT Guide/media/image40.png b/docs/APPC CDT Guide/media/image40.png deleted file mode 100644 index bd33a8841..000000000 Binary files a/docs/APPC CDT Guide/media/image40.png and /dev/null differ diff --git a/docs/APPC CDT Guide/media/image41.png b/docs/APPC CDT Guide/media/image41.png deleted file mode 100644 index 23d5511af..000000000 Binary files a/docs/APPC CDT Guide/media/image41.png and /dev/null differ diff --git a/docs/APPC CDT Guide/media/image42.png b/docs/APPC CDT Guide/media/image42.png deleted file mode 100644 index c870cfbb7..000000000 Binary files a/docs/APPC CDT Guide/media/image42.png and /dev/null differ diff --git a/docs/APPC CDT Guide/media/image5.png b/docs/APPC CDT Guide/media/image5.png deleted file mode 100644 index 119e538db..000000000 Binary files a/docs/APPC CDT Guide/media/image5.png and /dev/null differ diff --git a/docs/APPC CDT Guide/media/image6.png b/docs/APPC CDT Guide/media/image6.png deleted file mode 100644 index aae3ba4a1..000000000 Binary files a/docs/APPC CDT Guide/media/image6.png and /dev/null differ diff --git a/docs/APPC CDT Guide/media/image7.png b/docs/APPC CDT Guide/media/image7.png deleted file mode 100644 index f4df3fc1d..000000000 Binary files a/docs/APPC CDT Guide/media/image7.png and /dev/null differ diff --git a/docs/APPC CDT Guide/media/image8.png b/docs/APPC CDT Guide/media/image8.png deleted file mode 100644 index b28bc1f8a..000000000 Binary files a/docs/APPC CDT Guide/media/image8.png and /dev/null differ diff --git a/docs/APPC CDT Guide/media/image9.png b/docs/APPC CDT Guide/media/image9.png deleted file mode 100644 index a48ecd2d4..000000000 Binary files a/docs/APPC CDT Guide/media/image9.png and /dev/null differ diff --git a/docs/APPC CDT Guide/media/imageA.png b/docs/APPC CDT Guide/media/imageA.png deleted file mode 100644 index 2e81595ed..000000000 Binary files a/docs/APPC CDT Guide/media/imageA.png and /dev/null differ diff --git a/docs/APPC Client Library Guide/APPC Client Library Guide.rst b/docs/APPC Client Library Guide/APPC Client Library Guide.rst deleted file mode 100644 index a819ed84c..000000000 --- a/docs/APPC Client Library Guide/APPC Client Library Guide.rst +++ /dev/null @@ -1,224 +0,0 @@ -.. ============LICENSE_START========================================== -.. =================================================================== -.. Copyright © 2017 AT&T Intellectual Property. All rights reserved. -.. =================================================================== -.. Licensed under the Creative Commons License, Attribution 4.0 Intl. (the "License"); -.. you may not use this documentation except in compliance with the License. -.. You may obtain a copy of the License at -.. -.. https://creativecommons.org/licenses/by/4.0/ -.. -.. Unless required by applicable law or agreed to in writing, software -.. distributed under the License is distributed on an "AS IS" BASIS, -.. WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. -.. See the License for the specific language governing permissions and -.. limitations under the License. -.. ============LICENSE_END============================================ - -.. _appc_client_library: - -========================= -APPC Client Library Guide -========================= - - -Introduction -============ - -Target Audience ---------------- - -This document is for an advanced technical audience, which includes engineers and technicians. Document revisions occur with the release of new software versions. - -Related Documentation ---------------------- - -For additional information, see - - :ref:`appc_api_guide` - - -Client Library Background -========================= - -This guide discusses the Application Controller (APPC) Client Library and how to use it. - -About the Client Library ------------------------- - -The APPC client library provides consumers of APPC capabilities with a strongly-typed Java interface and encapsulates the actual interaction with the APPC component over an asynchronous messaging channel such as DMaaP. - -Consumer Logic --------------- - -The client application that consumes APPC’s capability for VNF lifecycle management (the APPC client library) can be implemented against the lightweight and strongly-typed Java API exposed by the APPC client library. The library does not try to impose architectural constraints upon clients, but instead provides support for different options and styles of API. It is the responsibility of the client application to select the most suitable paradigm to use; for example, a client may choose to use blocking calls as opposed to asynchronous notifications. - -VNF Lifecycle Management API ----------------------------- - -The API represents a relatively thin layer that consists mainly of business interfaces with strongly-typed APIs and a data object model created for the convenience of the consumer application. The original YANG schema used by the APPC component and the underlying MD-SAL layer on the server-side generates these artifacts. - -APP-C Client Library Flow -------------------------- - - |image0| - -Asynchronous Flow -^^^^^^^^^^^^^^^^^ - -- The APPC Client Library is called using an asynchronous API utilizing a full command object, which is mapped to a JSON representation. -- The APPC client calls the DMaaP client and sends the JSON command to a configured topic. -- The APPC client pulls response messages from the configured topic. -- On receiving the response for the command, the APPC client runs the relevant callback method of the consumer ResponseHandler. - -Synchronous Flow -^^^^^^^^^^^^^^^^ - -- The APPC Client Library is called using a synchronous API using a full command object, which is mapped to a JSON representation. -- The APPC client calls the DMaaP client and sends the JSON command to a configured topic. -- The APPC client pulls response messages from the configured topic. -- On receiving the **final** response for the command, the APPC client returns the response object with a final status. - -Client Library Usage -==================== - -Jar Files ---------- - -The Java application that runs the APPC client kit uses the following jar files: - - - org.onap.appc.client:client-kit - - org.onap.appc.client:client-lib - -The client library JAR files are located in the repository under ``com\att\appc\client``. - -Initialization --------------- - -Initialize the client by calling the following method: - -``AppcClientServiceFactoryProvider.getFactory(AppcLifeCycleManagerServiceFactory.class).createLifeCycleManagerStateful()`` - -Specify the following configuration properties as method parameters: - - - "topic.read" - - "topic.read.timeout" - - "topic.write" - - "client.key" - - "client.secret" - - "client.name" - - "client.name.id" - - "poolMembers" - - “client.response.timeout” - - “client.graceful.shutdown.timeout” - - “controllerType” - -Shutdown --------- - -Shutdown the client by calling the following method, first if Controller Type is not included, the second when Controller Type is included: - -``void shutdownLifeCycleManager(boolean isForceShutdown)``, or -``void shutdownLifeCycleManager(boolean isForceShutdown, String controllerType)`` - -If the ``isForceShutdown`` flag is set to false, the client shuts down as soon as all responses for pending requests are received, or upon configurable timeout. (``client.graceful.shutdown.timeout``). - -If the ``isForceShutdown`` flag is set to true, the client shuts down immediately. - -Invoking LCM Commands ---------------------- - -Invoke the LCM commands by: - - - Creating input objects, such as AuditInput, LiveUpgradeInput, with relevant command information. - - Executing commands asynchronously, for example: - -``void liveUpgrade(LiveUpgradeInput liveUpgradeInput, ResponseHandler listener) throws AppcClientException;)`` - -In this case, client should implement the ResponseHandler interface. - - - Executing commands synchronously, for example: - -``LiveUpgradeOutput liveUpgrade(LiveUpgradeInput liveUpgradeInput) throws AppcClientException;)`` - - -Client API -========== - -After initializing the client, a returned Object of type LifeCycleManagerStateful defines all the Life Cycle Management APIs - supported by APPC. - -The interface contains two definitions for each RPC: one for Asynchronous call mode, and one for Synchronous. - -In Asynchronous mode, client consumer should provide a callback function of type: - - ``ResponseHandler`` - -where ``RPC-NAME`` is the command name, such as Audit or Snapshot. - -There may be multiple calls to the ResponseHandler for each response returned by APPC. For example, first 100 ‘accept’ is returned, then 400 ‘success’. - -LifeCycleManagerStateful Interface ----------------------------------- - -Generated from the APPC Yang model, this interface defines the services and request/response requirements for the ONAP APPC component. For example, for LCM Command Audit, the following is defined: - -``@RPC(name="audit", outputType=AuditOutput.class)`` - -``AuditOutput audit(AuditInput auditInput) throws AppcClientException;`` - -For a Synchronous call to Audit, the consumer thread is blocked until a response is received or a timeout exception is thrown. - -``@RPC(name="audit", outputType=AuditOutput.class)`` - -``void audit(AuditInput auditInput, ResponseHandler listener) throws AppcClientException;`` - -For an Asynchronous call to Audit, a callback should be provided so that when a response is received the listener is called. - -API documentation ------------------ - -The API documentation is also available as a swagger page generated from files at /client-kit/target/resources. - -appc-provider-lcm ------------------ - -This defines the services and request/response requirements for the APPC component. - -Methods -------- - -The methods should match the actions described in the LCM API Guide. For each method: - -**Consumes** - -This API call consumes the following media types using the**Content-Type** request header: - - - ``application/json`` - -**Request body** - -The request body is the action name followed by Input (e.g., AuditInput) - -**Return type** - -The return type is the action name followed by Output (e.g., OutputInput) - -**Produces** - -This API call produces the following media types according to the **Accept** request header; the **Content-Type** response header conveys the media type. - - - ``application/json`` - -**Responses** - -200 Successful operation - -401 Unauthorized - -500 Internal server error - -.. |image0| image:: image2.png - :width: 5.60495in - :height: 4.55272in - diff --git a/docs/APPC Client Library Guide/image2.png b/docs/APPC Client Library Guide/image2.png deleted file mode 100644 index bf988cdcb..000000000 Binary files a/docs/APPC Client Library Guide/image2.png and /dev/null differ diff --git a/docs/APPC LCM API Guide/APPC LCM API Guide.rst b/docs/APPC LCM API Guide/APPC LCM API Guide.rst deleted file mode 100644 index e35b7c9ea..000000000 --- a/docs/APPC LCM API Guide/APPC LCM API Guide.rst +++ /dev/null @@ -1,3098 +0,0 @@ -.. ============LICENSE_START========================================== -.. =================================================================== -.. Copyright © 2017-2018 AT&T Intellectual Property. All rights reserved. -.. =================================================================== -.. Licensed under the Creative Commons License, Attribution 4.0 Intl. (the "License"); -.. you may not use this documentation except in compliance with the License. -.. You may obtain a copy of the License at -.. -.. https://creativecommons.org/licenses/by/4.0/ -.. -.. Unless required by applicable law or agreed to in writing, software -.. distributed under the License is distributed on an "AS IS" BASIS, -.. WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. -.. See the License for the specific language governing permissions and -.. limitations under the License. -.. ============LICENSE_END============================================ -.. ECOMP is a trademark and service mark of AT&T Intellectual Property. - -.. _appc_api_guide: - -================== -APPC LCM API Guide -================== - -Introduction -============ - -This guide describes the APPC API that allows you to manage and control the life cycle of controlled virtual network functions (VNFs). - - -Target Audience ---------------- -This document is intended for an advanced technical audience, such as the engineers or architects who need to use this guide to develop an interfacing application. The guide assumes a knowledge of the Open Network Automation Platform (ONAP) components and features, and familiarity with JSON notation. - - -Life Cycle Management Commands -============================== - -APPC receives commands from external ONAP components, such as SO, Policy, DCAE, or the Portal, to manage the life cycle of virtual applications and their components. - -A virtual application is composed of the following layers of network technology: - -- Virtual Network Function (VNF) -- Virtual Network Function Component (VNFC) -- Virtual Machine (VM) - -A Life Cycle Management (LCM) command may affect one or more of these layers. - -An LCM command is sent as a request to the APPC using an HTTP POST request or in a message on a message bus (DMaaP). A request may result in either a single synchronous response or multiple asynchronous responses: - -- An **asynchronous** command, which is sent as an authorized and valid request, results in at least two discrete response events: - - an accept response, to indicate that the request is accepted for processing - - a final response to indicate the status and outcome of the request processing - - An unauthorized or invalid request results in a single ERROR response. - -- A **synchronous** command, such as Lock or Unlock, results in a single response that is either SUCCESS or ERROR. - -**NOTE:** For both asynchronous or synchronous commands, the first response is always returned using the same transport that the initial action used. For example, if the action request was via the message bus (such as when it originates from Policy), then the response is also via the message bus. However, if the request was via a direct HTTP call, the response is similarly a synchronous HTTP response. - - -Message Bus and the LCM API Client Library ------------------------------------------- - -The recommended approach for sending/receiving requests to APPC is via the message bus. To support this approach, an APPC client library is available and should be used. The client library aims to provide consumers of APPC capabilities with a strongly-typed Java interface and to encapsulate the actual interaction with APPC component via the message bus. - -For more details, see the APPC Client Library Guide at: - - :ref:`appc_client_library` - - -The client library supports both synchronous and asynchronous flows as follows. - -Asynchronous Flow -^^^^^^^^^^^^^^^^^ - -- The APPC Client Library is called via an asynchronous API using a full command object, which is mapped to a JSON representation. -- The APPC client calls the message bus client and sends the JSON command to a configured topic. -- The APPC client pulls response messages from the configured topic. -- On receiving the response for the command, APPC client runs the relevant callback method of the consumer ResponseHandler. - -Synchronous Flow -^^^^^^^^^^^^^^^^ - -- The APPC Client Library is called via a synchronous API using a full command object, which is mapped to a JSON representation. -- The APPC client calls the message bus client and sends the JSON command to a configured topic. -- The APPC client pulls response messages from the configured topic. -- On receiving the final response for the command, the APPC client returns the response object with a final status. - -The client library adds the following wrapper around request and responses to the LCM API (described below):: - - { - "version" : "2.0", - "cambria.partition" : "", - "correlation-id" :"", - "rpc-name" : "", - "type" : - "body" : - } - - - -Table 1 Request / Response Message Fields - -+----------------------+----------------------------------------------------------------------------------------------------------------+---------------------+ -| **Field** | **Description** | **Required** | -+======================+================================================================================================================+=====================+ -| version | Indicates the version of the message bus protocol with APPC. Version 2.0 should be used. | Yes | -+----------------------+----------------------------------------------------------------------------------------------------------------+---------------------+ -| cambria. partition | Indicates the specific topic partition that the message is intended for. For example: | No | -| | | | -| | - For incoming messages, this value should be ``APPC``. | | -| | | | -+----------------------+----------------------------------------------------------------------------------------------------------------+---------------------+ -| correlation- id | Correlation ID used for associating responses in APPC Client Library. | Yes | -| | Built as: ``-`` | | -+----------------------+----------------------------------------------------------------------------------------------------------------+---------------------+ -| rpc-name | The target Remote Processing Call (RPC) name which should match the LCM command name. For example:``configure``| Yes | -| | | | -| | The convention for RPC names and the target URL is that multi-word command names should have a dash between | | -| | words, e.g., | | -| | /restconf/operations/appc-provider-lcm:action-status | | -+----------------------+----------------------------------------------------------------------------------------------------------------+---------------------+ -| type | Message type: request, response or error | Yes | -+----------------------+----------------------------------------------------------------------------------------------------------------+---------------------+ -| body | Contains the input or output LCM command content, which is either the request or response | | -| | The body field format is identical to the equivalent HTTP Rest API command based on the specific RPC name. | Yes | -| | For example:: | | -| | | | -| | { | | -| | "input" : { | | -| | "common-header" : {...} | | -| | "action" : "configure", | | -| | "action-identifiers" : {...}, | | -| | "payload": "..." | | -| | } | | -+----------------------+----------------------------------------------------------------------------------------------------------------+---------------------+ - - -Generic Request Format ----------------------- - -The LCM API general request format is applicable for both POST HTTP API and for the message body received via the message bus. - -LCM Request -^^^^^^^^^^^ - -The LCM request comprises a common header and a section containing the details of the LCM action. -The LCM request conforms to the following structure:: - - { - "input": { - "common-header": {"timestamp": "", - "api-ver": "", - "originator-id": "", - "request-id": "", - "sub-request-id": "", - "flags": { - "mode": "", - "force": "", - "ttl": "" - } - }, - "action": "", - "action-identifiers": { - "vnf-id": "", - "vnfc-name": "", - "vserver-id": "VSERVER_ID" - }, - ["payload": ""] - } - } - - -Table 2 LCM Request Fields - -+---------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------+ -| **Field** | **Description** | **Required?** | -+===========================+=============================================================================================================================================================================================================================================================================================================================================================================+=====================+ -| input | The block that defines the details of the input to the command processing. Contains the common-header details. | Yes | -+---------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------+ -| common- header | The block that contains the generic details about a request. | Yes | -+---------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------+ -| timestamp | The time of the request, in ISO 8601 format, ZULU offset. For example: 2016-08-03T08:50:18.97Z. | Yes | -| | | | -| | APPC will reject the request if timestamp is in the future (due to clock error), or timestamp is too old (compared to TTL flag) | | -+---------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------+ -| api-ver | Identifies the API version, in X.YY format, where X denotes the major version increased with each APPC release, and YY is the minor release version. | Yes | -| | | | -| | 2.00 should be used for all LCM API requests | | -+---------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------+ -| originator-id | An identifier of the calling system limited to a length of 40 characters. | Yes | -| | | | -| | It can be used for addressing purposes, such as to return an asynchronous response to the correct destination, in particular where there are multiple consumers of APPC APIs. | | -+---------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------+ -| request-id | The UUID for the request ID, limited to a length of 40 characters. The unique OSS/BSS identifier for the request ID that triggers the current LCM action. Multiple API calls can be made with the same request-id. | Yes | -| | | | -| | The request-id is stored throughout the operations performed during a single request. | | -+---------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------+ -| sub-request-id | Uniquely identifies a specific LCM or control action, limited to a length of 40 characters. Persists throughout the life cycle of a single request. | No | -+---------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------+ -| flags | Generic flags that apply to all LCM actions: | No | -| | | | -| | - "MODE" : | | -| | | | -| | - "EXCLUSIVE" - reject requests on this VNF while another request is in progress, or | | -| | | | -| | - "NORMAL" - allow requests (pending additional validations) on this VNF if there is another request is in progress. | | -| | | | -| | - "FORCE" : | | -| | - **TRUE** – forces APPC to process the request regardless of whether there is another request for the VNF or VM in progress. | | -| | - **FALSE** – default value. Will return an error if there is another action in progress on the same VNF or VM, unless the two actions are allowed in parallel based on a Request Management Model stored in APPC. The model allows some non-disruptive actions such as Lock, Unlock, CheckLock, and ActionStatus to be performed in conjunction with other actions. | | -| | | | -| | | | -| | - "TTL": <0....N> - The timeout value is used to determine if the request timeout has been exceeded (i.e., if the TTL value is less than the current time minus the timestamp, the request is rejected). The value is in seconds. | | -| | | | -| | If no TTL value provided, the default/configurable TTL value is to be used. | | -+---------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------+ -| action | The action to be taken by APPC, for example: Test, Start | Yes | -| | | | -| | These are case-sensitive; e.g.,”Restart” is correct; “restart” is incorrect. | | -| | | | -| | ***NOTE:** The specific value for the action parameter is provided for each command. | | -+---------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------+ -| action-identifiers | A block containing the action arguments. These are used to specify the object upon which APPC LCM command is to operate. At least one action-identifier must be specified (note that vnf-id is mandatory). For actions that are at the VM level, the action-identifiers provided would be vnf-id and vserver-id. | Yes | -+---------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------+ -| service-instance-id | Identifies a specific service instance that the command refers to. When multiple APPC instances are used and applied to a subset of services, this will become significant. The field is mandatory when the vnf-id is empty. Currently not used. | No | -+---------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------+ -| vnf-id | Identifies the VNF instance to which this action is to be applied. Required for actions. | Yes | -+---------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------+ -| vnfc-name | Identifies the VNFC instance to which this action is to be applied. Required if the action applied to a specific VNFC. Currently not used. | No | -+---------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------+ -| vserver-id | Identifies a specific VM instance to which this action is to be applied. Required if the action applied to a specific VM. (Populate the vserver-id field with the UUID of the VM) | No | -+---------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------+ -| vf-module-id | Identifies a specific VF module to which this action is to be applied. Required if the action applied to a specific VF module. | No | -+---------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------+ -| payload | An action-specific open-format field. | No | -| | | | -| | The payload can be any valid JSON string value. JSON escape characters need to be added when an inner JSON string is included within the payload, for example: | | -| | | | -| | ``"{\" vnf-host-ip-address\": \"\"}"`` | | -| | | | -| | The payload is typically used to provide parametric data associated with the command, such as a list of configuration parameters. | | -| | | | -| | Note that not all LCM commands need have a payload. | | -| | | | -| | ***NOTE:** See discussion below on the use of payloads for self-service actions. | | -+---------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------+ - -Request Processing and Validation Logic -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -When a new request is received, APPC applies the following validation logic. For any failure, the request is rejected and an error (300 range) is returned. - -1. If the request has timeout (i.e., the difference between current - time and the request timestamp value is greater than TTL value in - request), a timeout error is returned. - -2. If the request is a duplicate of an existing request in progress - (same request-id, sub-request-id, originator-id), a duplicate error - is returned. - -3. If there is a Lock on the vnf-id, reject any new action if it is not - associated with the locking request-id, a lockout error is returned. - -4. If the Force flag = Y, then allow the new action regardless of - whether there is an action in progress. - -5. If the Mode flag = Exclusive on a request in progress, any new - request is rejected until the request in progress is completed. - -6. If request is received and there are one or more requests in - progress, then the new request is evaluated to determine if there is - any overlap in scope with the existing requests (for example, a new - VNF level request would overlap with another request in progress). - - a. If there is no overlap between the new request and requests in - progress, the new request is accepted. - - b. If there is overlap, then only special cases are allowed in - parallel (for example, Audit and HealthCheck are allowed). - - -Generic Response Format ------------------------ - - -This section describes the generic response format. - -The response format is applicable for both POST HTTP API and for the message body received via the message bus. - - -LCM Response -^^^^^^^^^^^^ - -The LCM response comprises a common header and a section containing the payload and action details. - -The LCM response conforms to the following structure:: - - { - "output": { - "common-header": { - "api-ver": "", - "flags": { - "ttl": , - "force": "", - "mode": "" - }, - "originator-id": "", - "request-id": "", - "sub-request-id": "", - "timestamp": "2016-08-08T23:09:00.11Z", - }, - "payload": "", - [Additional fields], - "status": { - "code": , - "message": "" - } - } - } - - -Table 3 LCM Response Fields - -+----------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------+ -| **Field** | **Description** | **Required?** | -+======================+===========================================================================================================================================================================================================================+=====================+ -| output | The block that defines the details of the output of the command processing. Contains the ``common-header`` details. | Yes | -+----------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------+ -| common- header | The block that contains the generic details about a request. | Yes | -+----------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------+ -| api-ver | Identifies the API version, in X.YY format, where X denotes the major version increased with each APPC release, and YY is the minor release version. | Yes | -| | | | -| | - 2.00 should be used for all LCM API requests | | -+----------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------+ -| originator-id | An identifier of the calling system limited to a length of 40 characters. | Yes | -| | | | -| | It can be used for addressing purposes, such as to return an asynchronous response to the correct destination, in particular where there are multiple consumers of APPC APIs. | | -+----------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------+ -| request-id | The UUID for the request ID, limited to a length of 40 characters. The unique OSS/BSS identifier for the request ID that triggers the current LCM action. Multiple API calls can be made with the same request- id. | Yes | -| | | | -| | The request-id is stored throughout the operations performed during a single request. | | -+----------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------+ -| sub-request-id | Uniquely identifies a specific LCM or control action, limited to a length of 40 characters. Persists throughout the life cycle of a single request. | No | -+----------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------+ -| timestamp | The time of the request, in ISO 8601 format, ZULU offset. For example: ``2016-08-03T08:50:18.97Z``. | Yes | -+----------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------+ -| status | The status describes the outcome of the command processing. Contains a ``code`` and a ``message`` providing success or failure details. | Yes | -| | | | -| | ***NOTE:** See* status *for code values.* | | -+----------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------+ -| payload | An open-format field. | No | -| | | | -| | The payload can be any valid JSON string value. JSON escape characters need to be added when an inner JSON string is included within the payload, for example: ``"{\\"upload\_config\_id\\": \\"", - "error-info": "" - } - ] - } - } - - -**Example Response**:: - - { - "errors": { - "error": [ - { - "error-type": "protocol", - "error-tag": "malformed-message", - "error-message": "Error parsing input: Invalid value 'Stopp' for - enum type. Allowed values are: [Sync, Audit, Stop, Terminate]", - "error-info": "java.lang.IllegalArgumentException: Invalid value - 'Stopp' for enum type. Allowed values are: [Sync, Audit, Stop, - Terminate]..." - } - ] - } - } - - - -API Scope -========= - -Defines the level at which the LCM command operates for the current release of APPC and the VNF types which are supported for each command. - - -Commands, or actions, can be performed at one or more of the following scope levels: - - -+-----------------+----------------------------------------------------------------------------------------+ -| **VNF** | Commands can be applied at the level of a specific VNF instance using the vnf-id. | -+-----------------+----------------------------------------------------------------------------------------+ -| **VF-Module** | Commands can be applied at the level of a specific VF-Module using the vf-module-id. | -+-----------------+----------------------------------------------------------------------------------------+ -| **VNFC** | Commands can be applied at the level of a specific VNFC instance using a vnfc-name. | -+-----------------+----------------------------------------------------------------------------------------+ -| **VM** | Commands can be applied at the level of a specific VM instance using a vserver-id. | -+-----------------+----------------------------------------------------------------------------------------+ - - -**VNF/VM Types Supported** - -Commands, or actions, may be currently supported on all VNF types or a limited set of VNF types. Note that the intent is to support all actions on all VNF types which have been successfully onboarded in a self-service mode. - - - **Any** Currently supported on any vnf-type. - - - **Any (requires self-service onboarding)** Currently supported on any vnf-type which has been onboarded using the APPC self-service onboarding process. See further discussion on self-service onboarding below. - - -+-----------------------------+-----------+------------------+----------------+----------+------------------------------------------------------------+ -| **Command** | **VNF** | **VF-Module** | **VNFC** | **VM** | **VNF/VM Types Supported** | -+=============================+===========+==================+================+==========+============================================================+ -| ActionStatus | Yes | | | | Any | -+-----------------------------+-----------+------------------+----------------+----------+------------------------------------------------------------+ -| ActivateNESw | Yes | | | | Chef and Ansible only (requires self-service onboarding) | -+-----------------------------+-----------+------------------+----------------+----------+------------------------------------------------------------+ -| AttachVolume | | | | Yes | Any (uses OpenStack command) | -+-----------------------------+-----------+------------------+----------------+----------+------------------------------------------------------------+ -| Audit | Yes | | | | Any (requires self-service onboarding) | -+-----------------------------+-----------+------------------+----------------+----------+------------------------------------------------------------+ -| CheckLock | Yes | | | | Any | -+-----------------------------+-----------+------------------+----------------+----------+------------------------------------------------------------+ -| Configure | Yes | | | | Any (requires self-service onboarding) | -+-----------------------------+-----------+------------------+----------------+----------+------------------------------------------------------------+ -| ConfigBackup | Yes | | | | Chef and Ansible only (requires self-service onboarding) | -+-----------------------------+-----------+------------------+----------------+----------+------------------------------------------------------------+ -| ConfigModify | Yes | | | | Any (requires self-service onboarding) | -+-----------------------------+-----------+------------------+----------------+----------+------------------------------------------------------------+ -| ConfigRestore | Yes | | | | Chef and Ansible only (requires self-service onboarding) | -+-----------------------------+-----------+------------------+----------------+----------+------------------------------------------------------------+ -| ConfigScaleIn | Yes | | Yes | Yes | Chef and Ansible only (requires self-service onboarding) | -+-----------------------------+-----------+------------------+----------------+----------+------------------------------------------------------------+ -| ConfigScaleOut | Yes | | | | Any (requires self-service onboarding) | -+-----------------------------+-----------+------------------+----------------+----------+------------------------------------------------------------+ -| DetachVolume | | | | Yes | Any (uses OpenStack command) | -+-----------------------------+-----------+------------------+----------------+----------+------------------------------------------------------------+ -| DistributeTraffic | Yes | | Yes | Yes | Chef and Ansible only (requires self-service onboarding) | -+-----------------------------+-----------+------------------+----------------+----------+------------------------------------------------------------+ -| DistributeTrafficCheck | Yes | | Yes | Yes | Chef and Ansible only (requires self-service onboarding) | -+-----------------------------+-----------+------------------+----------------+----------+------------------------------------------------------------+ -| DownloadNESw | Yes | | | | Chef and Ansible only (requires self-service onboarding) | -+-----------------------------+-----------+------------------+----------------+----------+------------------------------------------------------------+ -| Evacuate | | | | Yes | Any (uses OpenStack command) | -+-----------------------------+-----------+------------------+----------------+----------+------------------------------------------------------------+ -| GetConfig | Yes | | | | Ansible | -+-----------------------------+-----------+------------------+----------------+----------+------------------------------------------------------------+ -| HealthCheck | Yes | | | | Any (requires self-service onboarding) | -+-----------------------------+-----------+------------------+----------------+----------+------------------------------------------------------------+ -| LicenseManagement | Yes | | | | Ansible | -+-----------------------------+-----------+------------------+----------------+----------+------------------------------------------------------------+ -| Lock | Yes | | | | Any | -+-----------------------------+-----------+------------------+----------------+----------+------------------------------------------------------------+ -| Migrate | | | | Yes | Any (uses OpenStack command) | -+-----------------------------+-----------+------------------+----------------+----------+------------------------------------------------------------+ -| PostEvacuate | Yes | | | | Ansible | -+-----------------------------+-----------+------------------+----------------+----------+------------------------------------------------------------+ -| PostMigrate | Yes | | | | Ansible | -+-----------------------------+-----------+------------------+----------------+----------+------------------------------------------------------------+ -| PostRebuild | Yes | | | | Ansible | -+-----------------------------+-----------+------------------+----------------+----------+------------------------------------------------------------+ -| PreConfigure | Yes | | | | Ansible | -+-----------------------------+-----------+------------------+----------------+----------+------------------------------------------------------------+ -| PreEvacuate | Yes | | | | Ansible | -+-----------------------------+-----------+------------------+----------------+----------+------------------------------------------------------------+ -| PreMigrate | Yes | | | | Ansible | -+-----------------------------+-----------+------------------+----------------+----------+------------------------------------------------------------+ -| PreRebuild | Yes | | | | Ansible | -+-----------------------------+-----------+------------------+----------------+----------+------------------------------------------------------------+ -| Provisioning | Yes | | | | Ansible | -+-----------------------------+-----------+------------------+----------------+----------+------------------------------------------------------------+ -| QuiesceTraffic | Yes | | | | Chef and Ansible only (requires self-service onboarding) | -+-----------------------------+-----------+------------------+----------------+----------+------------------------------------------------------------+ -| Reboot | | | | Yes | Any (uses OpenStack command) | -+-----------------------------+-----------+------------------+----------------+----------+------------------------------------------------------------+ -| Rebuild | | | | Yes | Any (uses OpenStack command) | -+-----------------------------+-----------+------------------+----------------+----------+------------------------------------------------------------+ -| Restart | | | | Yes | Any (uses OpenStack command) | -+-----------------------------+-----------+------------------+----------------+----------+------------------------------------------------------------+ -| ResumeTraffic | Yes | | | | Chef and Ansible only (requires self-service onboarding) | -+-----------------------------+-----------+------------------+----------------+----------+------------------------------------------------------------+ -| Snapshot | | | | Yes | Any (uses OpenStack command) | -+-----------------------------+-----------+------------------+----------------+----------+------------------------------------------------------------+ -| Start | | | | Yes | Any (uses OpenStack command) | -+-----------------------------+-----------+------------------+----------------+----------+------------------------------------------------------------+ -| StartApplication | Yes | | | | Chef and Ansible only (requires self-service onboarding) | -+-----------------------------+-----------+------------------+----------------+----------+------------------------------------------------------------+ -| StartTraffic | Yes | | | | Ansible | -+-----------------------------+-----------+------------------+----------------+----------+------------------------------------------------------------+ -| StatusTraffic | Yes | | | | Ansible | -+-----------------------------+-----------+------------------+----------------+----------+------------------------------------------------------------+ -| Stop | | | | Yes | Any (uses OpenStack command) | -+-----------------------------+-----------+------------------+----------------+----------+------------------------------------------------------------+ -| StopApplication | Yes | | | | Chef and Ansible only (requires self-service onboarding) | -+-----------------------------+-----------+------------------+----------------+----------+------------------------------------------------------------+ -| StopTraffic | Yes | | | | Ansible | -+-----------------------------+-----------+------------------+----------------+----------+------------------------------------------------------------+ -| Sync | Yes | | | | Any (requires self-service onboarding) | -+-----------------------------+-----------+------------------+----------------+----------+------------------------------------------------------------+ -| Unlock | Yes | | | | Any | -+-----------------------------+-----------+------------------+----------------+----------+------------------------------------------------------------+ -| UpgradeBackout | Yes | | | | Chef and Ansible only (requires self-service onboarding) | -+-----------------------------+-----------+------------------+----------------+----------+------------------------------------------------------------+ -| UpgradeBackup | Yes | | | | Chef and Ansible only (requires self-service onboarding) | -+-----------------------------+-----------+------------------+----------------+----------+------------------------------------------------------------+ -| UpgradePostCheck | Yes | | | | Chef and Ansible only (requires self-service onboarding) | -+-----------------------------+-----------+------------------+----------------+----------+------------------------------------------------------------+ -| UpgradePreCheck | Yes | | | | Chef and Ansible only (requires self-service onboarding) | -+-----------------------------+-----------+------------------+----------------+----------+------------------------------------------------------------+ -| UpgradeSoftware | Yes | | | | Chef and Ansible only (requires self-service onboarding) | -+-----------------------------+-----------+------------------+----------------+----------+------------------------------------------------------------+ - - - -Self-Service VNF Onboarding ---------------------------- - -The APPC architecture is designed for VNF self-service onboarding (i.e., a VNF owner or vendor through the use of tools can enable a new VNF to support the LCM API actions that are designate as self-service). The VNF must support one or more of the following interface protocols: - -- Netconf with uploadable Yang model (requires a Netconf server running - on the VNF) - -- Chef (requires a Chef client running on the VNF) - -- Ansible (does not require any changes to the VNF software) - -The self-service onboarding process is done using an APPC Design GUI (also referred to as CDT) which interacts with an APPC instance which is dedicated to self-service onboarding. The steps in the onboarding process using the APPC Design GUI are: - -- Define the VNF capabilities (set of actions that the VNF can - support). - -- Create a template and parameter definitions for actions which use the - Netconf, Chef, or Ansible protocols. The template is an xml or JSON - block which defines the “payload” which is included in the request - that is downloaded the VNF (if Netconf) or Chef/Ansible server. - -- Test actions which have templates/parameter definitions. - -- Upload the VNF definition, template, and parameter definition - artifacts to SDC which distributes them to all APPC instances in the - same environment (e.g., production). - -For more details, see the APPC CDT Onboarding User Guide. - - - -LCM Commands -============ - -The LCM commands that are valid for the current release. - -ActionStatus ------------- - -The ActionStatus command returns that state of any action request that has been previously submitted to an APPC instance for a specified VNF. This enables the client to know the status of a previous request and helps them decide if they should reissue a request. - -+--------------------------+----------------------------------------------------------+ -| **Target URL** | /restconf /operations/ appc-provider-lcm:action-status | -+--------------------------+----------------------------------------------------------+ -| **Action** | ActionStatus | -+--------------------------+----------------------------------------------------------+ -| **Action-Identifiers** | vnf-id | -+--------------------------+----------------------------------------------------------+ -| **Payload Parameters** | See below | -+--------------------------+----------------------------------------------------------+ -| **Revision History** | New in Beijing | -+--------------------------+----------------------------------------------------------+ - -| - -+-----------------------------+------------------------------------------------------------+--------------------+-------------------------------------+ -| **Payload Parameter** | **Description** | **Required** | **Example** | -+=============================+============================================================+====================+=====================================+ -| request-id | Request id from the previously submitted request | Yes | "request-id": "123456789" | -+-----------------------------+------------------------------------------------------------+--------------------+-------------------------------------+ -| sub-request ID | Sub-Request id from the previously submitted request | optional | "sub-request-id": "123456789" | -+-----------------------------+------------------------------------------------------------+--------------------+-------------------------------------+ -| originator-id | Originator id from the previously submitted request | optional | "originator-id": "123456789" | -+-----------------------------+------------------------------------------------------------+--------------------+-------------------------------------+ - - -ActionStatus Response: -^^^^^^^^^^^^^^^^^^^^^^ - -A successful response contains a payload with the following: - -+-----------------------------+-----------------------------------------------------------------------+--------------------+------------------------------+ -| **Payload Parameter** | **Description** | **Required** | **Example** | -+=============================+=======================================================================+====================+==============================+ -| status-reason | Contains more details about status | No | | -+-----------------------------+-----------------------------------------------------------------------+--------------------+------------------------------+ -| status | IN_PROGRESS – The request has been accepted and is in progress | No | "status": "SUCCESSFUL" | -| | | | | -| | SUCCESSFUL – The request returned success message | | | -| | | | | -| | FAILED – The request failed and returned an error message | | | -| | | | | -| | ABORTED – the request aborted | | | -| | | | | -| | NOT_FOUND – The request is not found | | | -+-----------------------------+-----------------------------------------------------------------------+--------------------+------------------------------+ - -If the ActionStatus request was rejected or could not be processed, it returns a valid error code or error message (but no payload).Example below: - - ``"message": "MULTIPLE REQUESTS FOUND - using search criteria: - request- id=c09ac7d1-de62-0016-2000-e63701125559 AND - vnf-id=ctsf0007v", "code": 315`` - -ActivateNESw ---------------- - -The ActivateNESw LCM action activates the target software version needed for a software upgrade. - -This command is executed using an Ansible playbook or Chef cookbook. - -Request Structure: - -+--------------------------+------------------------------------------------------------+ -| **Target URL** | /restconf/operations/appc-provider-lcm:activate-n-e-sw | -+--------------------------+------------------------------------------------------------+ -| **Action** | ActivateNESw | -+--------------------------+------------------------------------------------------------+ -| **Action-identifiers** | vnf-id | -+--------------------------+------------------------------------------------------------+ -| **Payload Parameters** | See below | -+--------------------------+------------------------------------------------------------+ -| **Revision History** | New in Frankfurt | -+--------------------------+------------------------------------------------------------+ - -Request Payload Parameters: - -+--------------------------+-------------------------------------+---------------------+-----------------------------------------------------------------------------------------------+ -| **Parameter** | **Description** | **Required?** | **Example** | -+==========================+=====================================+=====================+===============================================================================================+ -| swVersionToBeActivated | The software to be activated | Yes | "payload": | -| | | | "{\"swVersionToBeActivated\": \"v2\"}" | -+--------------------------+-------------------------------------+---------------------+-----------------------------------------------------------------------------------------------+ - -ActivateNESw Response -^^^^^^^^^^^^^^^^^^^^^^^^ - -**Success:** If the ActivateNESw runs successfully, it returns a success status code 400. The response payload contains the results of the activating. - -Response Payload Parameters: - -+-----------------+-----------------------------+---------------------+------------------------------------------------------------------------------------------------------------------------------+ -| **Parameter** | **Description** | **Required?** | **Example** | -+=================+=============================+=====================+==============================================================================================================================+ -| result | Returns the result | Yes | | -| | of the activate-n-e-sw. | | "payload": | -| | Indicates Success or | | "{\\"result\\": \\"Success\\"}” | -| | Failure. | | | -+-----------------+-----------------------------+---------------------+ | -| reason | If not Success, | | | -| | reason contains | | | -| | explanation. | | | -+-----------------+-----------------------------+---------------------+------------------------------------------------------------------------------------------------------------------------------+ - -**Failure:** If an ActivateNESw fails to run, it returns a failure code 401 and the failure reason from the Ansible or Chef server in the response payload block. - -AttachVolume ------------- - -The AttachVolume command attaches a cinder volume to a VM via an Openstack command. - -Cinder is a Block Storage service for OpenStack. It's designed to present storage resources to end users that can be consumed by the OpenStack Compute Project (Nova). The short description of Cinder is that it virtualizes the management of block storage devices and provides end users with a self service API to request and consume those resources without requiring any knowledge of where their storage is actually deployed or on what type of device. - - NOTE: The command implementation is based on Openstack - functionality. For further details, see - http://developer.openstack.org/api-ref/compute/. - -+--------------------------+----------------------------------------------------------+ -| **Target URL** | /restconf/operations/appc-provider-lcm:attach-volume | -+--------------------------+----------------------------------------------------------+ -| **Action** | AttachVolume | -+--------------------------+----------------------------------------------------------+ -| **Action-Identifiers** | vnf-id, vserver-id | -+--------------------------+----------------------------------------------------------+ -| **Payload Parameters** | See table | -+--------------------------+----------------------------------------------------------+ -| **Revision History** | New in Beijing | -+--------------------------+----------------------------------------------------------+ - -| - -+-----------------------------+------------------------------------------------------+--------------------+---------------------------------------------------------------------------------------------------------------------------+ -| **Payload Parameter** | **Description** | **Required** | **Example** | -+=============================+======================================================+====================+===========================================================================================================================+ -| volumeId | The UUID of the volume to attach. | Yes | "volumeId": "a26887c6-c47b-4654-abb5-dfadf7d3f803", | -+-----------------------------+------------------------------------------------------+--------------------+---------------------------------------------------------------------------------------------------------------------------+ -| device | The device identifier | Yes | "device": "/dev/vdb" | -+-----------------------------+------------------------------------------------------+--------------------+---------------------------------------------------------------------------------------------------------------------------+ -| vm-id | TThe self- link URL of the VM. | Yes | "vm-id": http://135.25.246.162:8774/v2/64af07e991424b8e9e54eca27d5c0d48/servers/b074cd1b-8d53-412e-a102-351cc51ac10a" | -+-----------------------------+------------------------------------------------------+--------------------+---------------------------------------------------------------------------------------------------------------------------+ -| Identity-url | The identity URL used to access the resource | Yes | "identity-url": "http://135.25.246.162:5000/v2.0" | -+-----------------------------+------------------------------------------------------+--------------------+---------------------------------------------------------------------------------------------------------------------------+ - -AttachVolume Response: -^^^^^^^^^^^^^^^^^^^^^^ - -Success: A successful AttachVolume returns a success status code 400. - -Failure: A failed AttachVolume returns a failure code 401 and the failure message. Failure messages can include: - -- badRequest -- unauthorized -- forbidden -- itemNotFound - - -Audit ------ - -The Audit command compares the configuration of the VNF associated with the current request against the most recent configuration that is stored in APPC's configuration database. - -A successful Audit means that the current VNF configuration matches the latest APPC stored configuration. - -A failed Audit indicates that the configurations do not match. - -This command can be applied to any VNF type. The only restriction is that the VNF has been onboarded in self-service mode (which requires that the VNF supports a request to return the running configuration). - -The Audit action does not require any payload parameters. - -**NOTE:** Audit does not return a payload containing details of the comparison, only the Success/Failure status. - - -+------------------------------+------------------------------------------------------+ -| **Target URL** | /restconf/operations/appc-provider-lcm:audit | -+------------------------------+------------------------------------------------------+ -| **Action** | Audit | -+------------------------------+------------------------------------------------------+ -| **Action-Identifiers** | vnf-id | -+------------------------------+------------------------------------------------------+ -| **Payload Parameters** | See below | -+------------------------------+------------------------------------------------------+ -| **Revision History** | Unchanged in this release. | -+------------------------------+------------------------------------------------------+ - -| - -+----------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------+----------------------------------+ -| **Parameter** | **Description** | **Required?** | **Example** | -+======================+===========================================================================================================================================================+=====================+==================================+ -| publish-config | \* If the publish\-config field is set to Y in the payload, then always send the running configuration from the VNF using the message bus | Yes | "publish-config": "" | -| | | | | -| | \* If the publish\-config field is set to N in the payload, then: | | | -| | | | | -| | - If the result of the audit is ‘match’ (latest APPC config and the running config match), do not send the running configuration | | | -| | | | | -| | - If the result of the audit is ‘no match’, then send the running configuration | | | -+----------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------+----------------------------------+ - -Audit Response -^^^^^^^^^^^^^^ - -The audit response returns an indication of success or failure of the audit. If a new configuration is uploaded to the APPC database, the payload contains the ‘upload\_config\_id’ and values for any records created. In addition, the configuration is sent to the bus which may be received by an external configuration storage system. - - -CheckLock ---------- - -The CheckLock command returns true if the specified VNF is locked; otherwise, false is returned. - -A CheckLock command is deemed successful if the processing completes without error, whether the VNF is locked or not. The command returns only a single response with a final status. - -Note that APPC locks the target VNF during any VNF command processing, so a VNF can have a locked status even if no Lock command has been explicitly called. - -The CheckLock command returns a specific response structure that extends the default LCM response. - -The CheckLock action does not require any payload parameters. - -+------------------------------+--------------------------------------------------------+ -| **Target URL** | /restconf/operations/appc-provider-lcm:checklock | -+------------------------------+--------------------------------------------------------+ -| **Action** | CheckLock | -+------------------------------+--------------------------------------------------------+ -| **Action-Identifiers** | vnf-id | -+------------------------------+--------------------------------------------------------+ -| **Payload Parameters** | None | -+------------------------------+--------------------------------------------------------+ -| **Revision History** | Unchanged in this release. | -+------------------------------+--------------------------------------------------------+ - -CheckLock Response -^^^^^^^^^^^^^^^^^^ - -The CheckLock command returns a customized version of the LCM -response. - - -+---------------------+---------------------------------------------------------------------------------------+--------------------+---------------------------------+ -| **Parameter** | **Description** | **Required** | **?Example** | -+=====================+=======================================================================================+====================+=================================+ -| locked | "TRUE"\|"FALSE" - returns TRUE if the specified VNF is locked, otherwise FALSE. | No | "locked": "" | -+---------------------+---------------------------------------------------------------------------------------+--------------------+---------------------------------+ - - -**Example**:: - - { - "output": { - "status": { - "code": , "message": "" - }, - "common-header": { - "api-ver": "", - "request-id": "", "originator-id": - "", - "sub-request-id": "", "timestamp": - "2016-08-08T23:09:00.11Z", - "flags": { - "ttl": , "force": "", - "mode": "" - } - }, - "locked": "" - } - - -Configure ---------- - -Configure a VNF or a VNFC on the VNF after instantiation. - -A set of configuration parameter values specified in the configuration template is included in the request. Other configuration parameter values may be obtained from an external system. - -A successful Configure request returns a success response. - -A failed Configure action returns a failure response and the specific failure messages in the response block. - -+------------------------------+--------------------------------------------------------+ -| **Target URL** | /restconf/operations/appc-provider-lcm:configure | -+------------------------------+--------------------------------------------------------+ -| **Action** | Configure | -+------------------------------+--------------------------------------------------------+ -| **Action-Identifiers** | vnf-id | -+------------------------------+--------------------------------------------------------+ -| **Payload Parameters** | See below | -+------------------------------+--------------------------------------------------------+ -| **Revision History** | Unchanged in this release. | -+------------------------------+--------------------------------------------------------+ - -| - -+---------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------+-----------------------------------------------------------------+ -| **Payload Parameter** | **Description** | **Required?** | **Example** | -| | | | | -+=================================+================================================================================================================================================================================================================+=====================+=================================================================+ -| request-parameters | vnf-host-ip-address: optional if Netconf or other direct interface to the VNF. If not provided, APPC will look for the host-ip-address in the A&AI VNF oam ipv4 address field. | No | | -| | | | "payload": | -| | vnfc-type: must be included if template is vnfc specific | | "{ \\"request-parameters | -| | | | \\": { | -| | | | \\"vnf-host-ip-address\\": | -| | | | \\”value\\”, | -| | | | \\”vnfc-type\\”: \\”value\\”’ | -| | | | } | -| | | | | -| | | | | -| | | | | -| | | | | -| | | | | -| | | | | -| | | | | -| | | | | -| | | | | -+---------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------+ | -| configuration-parameters | A set of instance specific configuration parameters should be specified. If provided, APPC replaces variables in the configuration template with the values supplied. | No | \\"configuration- parameters\\": {\\"\\"} | -+---------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------+-----------------------------------------------------------------+ - - -Configure Response -^^^^^^^^^^^^^^^^^^ - -The Configure response returns an indication of success or failure of the request. - -**Success:** A successful Configure returns a success status code 400. -**Failure:** A failed Configure returns a failure code 401 and the failure message. - -If successful, the return payload contains the ‘upload_config_id’ and values for any records created in the APPC DB. In addition, the configuration is sent to the ONAP Data Router bus which may be received by an external configuration storage system. - -If APPC in unable to update A&AI with the VNFC records, a 501 intermediate error message returned prior to the final 400 or 401 success message. - -ConfigModify ------------- - -Modifies the configuration on a VNF or VNFC in service. - -This command is executed either directly on the VNF (such as for Netconf) or using an Ansible playbook or Chef cookbook. - -Request Structure: - -+--------------------------+--------------------------------------------------------+ -| **Target URL** | /restconf/operations/appc-provider-lcm:config-modify | -+--------------------------+--------------------------------------------------------+ -| **Action** | ConfigModify | -+--------------------------+--------------------------------------------------------+ -| **Action-Identifiers** | vnf-id | -+--------------------------+--------------------------------------------------------+ -| **Payload Parameters** | request-parameters, configuration-parameters | -+--------------------------+--------------------------------------------------------+ -| **Revision History** | Unchanged in this release. | -+--------------------------+--------------------------------------------------------+ - -Request Payload Parameters: - -+-------------------------+----------------------------------------+-----------------+-------------------------------------------------------+ -| **Payload Parameter** | **Description** | **Required?** | **Example** | -+=========================+========================================+=================+=======================================================+ -| request-parameters | vnf-host-ip-address: optional if | No | "payload": | -| | Netconf or other direct interface | | "{\\"request-parameters \\": | -| | to the VNF. If not provided, it is | | {\\"vnf-host-ip-address\\": \\”value\\", | -| | obtained from A&AI | | \\”vnfc-type\\”: \\”value\\” | -| | | | } | -| | | | | -| | vnfc-type: must be included if template| | | -| | is vnfc specific | | | -| | | | \\"configuration- parameters\\": {\\"name1\\": | -| | | | \\”value1\\”,\\"name2\\": | -| | | | \\”value2\\” | -| | | | } | -| | | | } | -+-------------------------+----------------------------------------+-----------------+ | -| configuration- | A set of instance specific | No | | -| parameters | configuration parameters should | | | -| | be specified. | | | -+-------------------------+----------------------------------------+-----------------+-------------------------------------------------------+ - -ConfigModify Request -^^^^^^^^^^^^^^^^^^^^ - - Examples:: - - { - "input": { - "common-header": { - "timestamp": "2017-10-25T11:10:04.244Z", - "api-ver": "2.00", - "originator-id": "664be3d2-6c12-4f4b-a3e7-c349acced200", - "request-id": "664be3d2-6c12-4f4b-a3e7-c349acced200", - "sub-request-id": "1", - "flags": { - "force": "TRUE", - "ttl": 60000 - } - }, - "action": "ConfigModify", - "action-identifiers": { - "vnf-id": "" - }, - "payload": "{ \"config-url\":\"5f517fd4-bf3d-43bc-8147-1b61776d7ded\", - \"config-json\": \"{\"pg-streams\":{ - \"pg-stream\": [{ \"id\":\"fw_udp1\", \"is-enabled\": \"true\" }, - {\"id\": \"fw_udp2\", \"is-enabled\":\"true\" }, - { \"id\": \"fw_udp3\",\"is-enabled\": \"true\" }, - { \"id\":\"fw_udp4\", \"is-enabled\": \"true\" }, - {\"id\": \"fw_udp5\", \"is-enabled\":\"true\" }]}}" - } - } - } - - -ConfigModify Response -^^^^^^^^^^^^^^^^^^^^^ - -**Success:** A successful ConfigModify returns a success status code 400. - -If successful, the return payload contains the ‘upload_config_id’ and values associated with the configuration stored in the APPC DB. In addition, the configuration is sent to the message bus which may be received by an external configuration storage system. - -**Failure:** A failed ConfigModify returns a failure code 401 and the failure message. - -ConfigBackup ------------- - -Stores the current VNF configuration on a local file system (not in APPC). This is limited to Ansible and Chef. There can only be one stored configuration (if there is a previously saved configuration, it is replaced with the current VNF configuration). - -A successful ConfigBackup request returns a success response. - -A failed ConfigBackup action returns a failure response code and the specific failure message in the response block. - -+------------------------------+-----------------------------------------------------------+ -| **Target URL** | /restconf/operations/appc-provider-lcm:config-backup | -+------------------------------+-----------------------------------------------------------+ -| **Action** | ConfigBackup | -+------------------------------+-----------------------------------------------------------+ -| **Action-Identifiers** | Vnf-id | -+------------------------------+-----------------------------------------------------------+ -| **Payload Parameters** | See below | -+------------------------------+-----------------------------------------------------------+ -| **Revision History** | Unchanged in this release. | -+------------------------------+-----------------------------------------------------------+ - -| - -+---------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------+-------------------------------------------------------------------+ -| **Payload Parameter** | **Description** | **Required?** | **Example** | -+=================================+====================================================================================================================================================================================+=====================+===================================================================+ -| request-parameters | Not used. This request is limited to Ansible and Chef only. | No | "payload": \\"configuration-parameters\\": {\\"\\"}| -| | | | | -| | | | | -| | | | | -| | | | | -| | | | | -+---------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------+ | -| configuration-parameters | A set of instance specific configuration parameters should be specified, as required by the Chef cookbook or Ansible playbook. | No | | -+---------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------+-------------------------------------------------------------------+ - -ConfigBackup Response -^^^^^^^^^^^^^^^^^^^^^ - -The ConfigBackup response returns an indication of success or failure of the request. - -**Success:** A successful ConfigBackup returns a success status code 400. -**Failure:** A failed ConfigBackup returns a failure code 401 and the failure message. - - -ConfigRestore -------------- - -Applies a previously saved configuration to the active VNF configuration. This is limited to Ansible and Chef. There can only be one stored configuration. - -A successful ConfigRestore request returns a success response. - -A failed ConfigRestore action returns a failure response code and the specific failure message in the response block. - -+------------------------------+------------------------------------------------------------------------------------------+ -| **Target URL** | /restconf/operations/appc-provider-lcm:config-restore | -+------------------------------+------------------------------------------------------------------------------------------+ -| **Action** | ConfigRestore | -+------------------------------+------------------------------------------------------------------------------------------+ -| **Action-Identifiers** | Vnf-id | -+------------------------------+------------------------------------------------------------------------------------------+ -| **Payload Parameters** | See below | -+------------------------------+------------------------------------------------------------------------------------------+ -| **Revision History** | Unchanged in this release. | -+------------------------------+------------------------------------------------------------------------------------------+ - -| - -+---------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------+-----------------------------------------------------------------+ -| **Parameter** | **Description** | **Required?** | **Example** | -+=================================+====================================================================================================================================================================================+=====================+=================================================================+ -| request-parameters | Not used. This request is limited to Ansible and Chef only. | No | "payload": | -| | | | \\"configuration-parameters\\": {\\"\\"} | -+---------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------+ | -| configuration-parameters | A set of instance specific configuration parameters should be specified, as required by the Chef cookbook or Ansible playbook. | No | | -+---------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------+-----------------------------------------------------------------+ - -ConfigRestore Response -^^^^^^^^^^^^^^^^^^^^^^ - -**Success:** A successful ConfigRestore returns a success status code 400. - -If successful, the return payload contains the ‘upload_config_id’ and values associated with the configuration stored in the APPC DB. In addition, the configuration is sent to the ONAP Data Router bus which may be received by an external configuration storage system. - -**Failure:** A failed ConfigRestore returns a failure code 401 and the failure message. - - -ConfigScaleIn -------------- - -The ConfigScaleIn command is used to apply any actions on a VNF as part of a ScaleIn flow. Actions could include updating the VNF configuration or running a set of other tasks. - -The ConfigScaleIn action can have multiple APPC templates associated with it. APPC retrieves the VfModuleModelName from A&AI (model.model-vers.model-name), which is used as the unique identifier to select the correct APPC template. -APPC creates or updates VNFC records in A&AI for the newly instantiated VM’s. The orchestration-status of the VNFC’s is set to CONFIGURED. - -This action is supported via the Netconf (limited to configuration changes), Chef, and Ansible protocols. - -| - -+------------------------------+------------------------------------------------------------------------------------------+ -| **Target URL** | /restconf /operations/appc-provider-lcm:config-scale-in | -+------------------------------+------------------------------------------------------------------------------------------+ -| **Action** | ConfigScaleIn | -+------------------------------+------------------------------------------------------------------------------------------+ -| **Action-Identifiers** | Vnf-id | -+------------------------------+------------------------------------------------------------------------------------------+ -| **Payload Parameters** | See below | -+------------------------------+------------------------------------------------------------------------------------------+ -| **Revision History** | New in Frankfurt | -+------------------------------+------------------------------------------------------------------------------------------+ - -| - -+---------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------+---------------------------------------------+ -| **Payload Parameter** | **Description** | **Required?** | **Example** | -+=================================+==================================================================================================================================================================+=====================+=============================================+ -| request-parameters | vnf-host-ip-address: optional if Netconf or other direct interface to the VNF. If not provided, the vnf-host-ip-address will be obtained from A&AI. | No | "payload": | -| +------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------+ "{\\"request-parameters \\": | -| | vf-module-id: used to determine the A&AI VM inventory associated with ConfigScaleIn. | Yes | { | -| +------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------+ \\"vnf-host-ip-address\\": | -| | controller-template-id: optional. This is a unique identifier that will identify the template associated with the ConfigScaleIn. | | \\”value\\”, | -| | Will be needed if A&AI does not contain the template identifier. | No | \\”vf-module-id\\”: \\”value\\”, | -+---------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------+ \\”controller-template-id\\”: | -| configuration-parameters | A set of instance specific configuration parameters should be specified. If provided, APP-C replaces variables in the configuration template with the | No | \\”value\\” | -| | values supplied. | | } | -| | | | | -| | | | \\"configuration-parameters\\": | -| | | | {\\"\\"} | -| | | | | -+---------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------+---------------------------------------------+ - -ConfigScaleIn Response -^^^^^^^^^^^^^^^^^^^^^^ - -**Success:** - - - A successful ConfigScaleIn returns a success status code 400 when completed. - -**Failure:** - - - A failed ConfigScaleIn returns a failure code 401 and the failure message. - - If the ConfigScaleIn is successfully performed on the VNF but there is a failure to update A&AI inventory, an intermediate failure message with failure code 501 is returned prior to the final 400 success message. - - - -ConfigScaleOut --------------- - -The ConfigScaleOut command is used to apply any actions on a VNF as part of a ScaleOut flow. Actions could include updating the VNF configuration or running a set of other tasks. - -The ConfigScaleOut action can have multiple APPC templates associated with it. APPC retrieves the VfModuleModelName from A&AI (model.model-vers.model-name), which is used as the unique identifier to select the correct APPC template. -APPC creates or updates VNFC records in A&AI for the newly instantiated VM’s. The orchestration-status of the VNFC’s is set to CONFIGURED. - -This action is supported via the Netconf (limited to configuration changes), Chef, and Ansible protocols. - -| - -+------------------------------+------------------------------------------------------------------------------------------+ -| **Target URL** | /restconf /operations/appc-provider-lcm:config-scale-out | -+------------------------------+------------------------------------------------------------------------------------------+ -| **Action** | ConfigScaleOut | -+------------------------------+------------------------------------------------------------------------------------------+ -| **Action-Identifiers** | Vnf-id | -+------------------------------+------------------------------------------------------------------------------------------+ -| **Payload Parameters** | See below | -+------------------------------+------------------------------------------------------------------------------------------+ -| **Revision History** | New in Beijing | -+------------------------------+------------------------------------------------------------------------------------------+ - -| - -+---------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------+---------------------------------------------+ -| **Payload Parameter** | **Description** | **Required?** | **Example** | -+=================================+==================================================================================================================================================================+=====================+=============================================+ -| request-parameters | vnf-host-ip-address: optional if Netconf or other direct interface to the VNF. If not provided, the vnf-host-ip-address will be obtained from A&AI. | No | "payload": | -| +------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------+ "{\\"request-parameters \\": | -| | vf-module-id: used to determine the A&AI VM inventory associated with ConfigScaleOut. | Yes | { | -| +------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------+ \\"vnf-host-ip-address\\": | -| | controller-template-id: optional. This is a unique identifier that will identify the template associated with the ConfigScaleOut. | | \\”value\\”, | -| | Will be needed if A&AI does not contain the template identifier. | No | \\”vf-module-id\\”: \\”value\\”, | -+---------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------+ \\”controller-template-id\\”: | -| configuration-parameters | A set of instance specific configuration parameters should be specified. If provided, APP-C replaces variables in the configuration template with the | No | \\”value\\” | -| | values supplied. | | } | -| | | | | -| | | | \\"configuration-parameters\\": | -| | | | {\\"\\"} | -| | | | | -+---------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------+---------------------------------------------+ - -ConfigScaleOut Response -^^^^^^^^^^^^^^^^^^^^^^^ - -**Success:** - - - A successful ConfigScaleOut returns a success status code 400 when completed. - -**Failure:** - - - A failed ConfigScaleOut returns a failure code 401 and the failure message. - - If the ConfigScaleOut is successfully performed on the VNF but there is a failure to update A&AI inventory, an intermediate failure message with failure code 501 is returned prior to the final 400 success message. - - -DetachVolume ------------- - -The DetachVolume command detaches a cinder volume from a VM via an Openstack command. - -Cinder is a Block Storage service for OpenStack. It's designed to present storage resources to end users that can be consumed by the OpenStack Compute Project (Nova). The short description of Cinder is that it virtualizes the management of block storage devices and provides end users with a self-service API to request and consume those resources without requiring any knowledge of where their storage is actually deployed or on what type of device. - -NOTE: The command implementation is based on Openstack functionality. For further details, see http://developer.openstack.org/api-ref/compute/. - -+--------------------------+----------------------------------------------------------+ -| **Target URL** | /restconf/operations/appc-provider-lcm:detach-volume | -+--------------------------+----------------------------------------------------------+ -| **Action** | DetachVolume | -+--------------------------+----------------------------------------------------------+ -| **Action-Identifiers** | vnf-id, vserver-id | -+--------------------------+----------------------------------------------------------+ -| **Payload Parameters** | See table | -+--------------------------+----------------------------------------------------------+ -| **Revision History** | New in Beijing | -+--------------------------+----------------------------------------------------------+ - -Request Payload Parameters: - -+-----------------------------+----------------------------------------------------------------+--------------------+--------------------------------------------------------------------------------------------------------------------------------+ -| **Payload Parameter** | **Description** | **Required** | **Example** | -+=============================+================================================================+====================+================================================================================================================================+ -| volumeId | The UUID of the volume to detach. | Yes | "volumeId": "a26887c6-c47b-4654-abb5-dfadf7d3f803" | -+-----------------------------+----------------------------------------------------------------+--------------------+--------------------------------------------------------------------------------------------------------------------------------+ -| vm-id | The self- link URL of the VM. | Yes | "vm-id": http://135.25.246.162:8774/v2/64af07e991424b8e9e54eca27d5c0d48/servers/b074cd1b-8d53-412e-a102-351cc51ac10a" | -+-----------------------------+----------------------------------------------------------------+--------------------+--------------------------------------------------------------------------------------------------------------------------------+ -| Identity-url | The identity URL used to access the resource | Yes | "identity-url": "http://135.25.246.162:5000/v2.0" | -+-----------------------------+----------------------------------------------------------------+--------------------+--------------------------------------------------------------------------------------------------------------------------------+ - -DetachVolume Response: -^^^^^^^^^^^^^^^^^^^^^^ - -**Success:** A successful DetachVolume returns a success status code 400. - -**Failure:** A failed DetachVolume returns a failure code 401 and the failure message. Failure messages can include: - - - badRequest - - unauthorized - - forbidden - - itemNotFound - - conflict - -DistributeTraffic ------------------ - -The Distribute Traffic LCM action is used to distribute traffic across different instances of VNF, VNFC or VM. -The entity for which Distribute Traffic LCM action is being invoked is called an anchor point that is responsible for final -realization of request. Parameters present in configuration file specify where and how traffic should be distributed, -including: traffic destination points like VNFs, VNFCs or VMs; distribution weights; rollback strategy. -Format of configuration file is specific to each VNF type. The Optimization Framework component and Homing, Allocation and -Placement mechanism can be used to retrieve instances of vf-modules of anchor points and destination points with -corresponding policies. - -This command is executed using an Ansible playbook or Chef cookbook. - -Request Structure: - -+--------------------------+--------------------------------------------------------------+ -| **Target URL** | /restconf/operations/appc-provider-lcm:distribute-traffic | -+--------------------------+--------------------------------------------------------------+ -| **Action** | DistributeTraffic | -+--------------------------+--------------------------------------------------------------+ -| **Action-identifiers** | vnf-id, vserver-id, vnfc-name | -+--------------------------+--------------------------------------------------------------+ -| **Payload Parameters** | See below | -+--------------------------+--------------------------------------------------------------+ -| **Revision History** | New in Casablanca | -+--------------------------+--------------------------------------------------------------+ - -Request Payload Parameters: - -+---------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------+------------------------------------------------------------------------------+ -| **Parameter** | **Description** | **Required?** | **Example** | -+=================================+==================================================================================================================================================================+=====================+==============================================================================+ -| configuration-parameters | A set of instance specific configuration parameters should be specified. If provided, APP-C replaces variables in the configuration template with the | No | "payload": "{\"configuration-parameters\": {\"file_parameter_content\": | -| | values supplied. The parameters are associated with request template defined with CDT | | \"{\\\"destinations\\\": [{\\\"locationType\\\": \\\"att_aic\\\", | -| | | | \\\"isRehome\\\": \\\"false\\\", \\\"aic_version\\\": \\\"1\\\", | -| | | | \\\"ipv4-oam-address\\\": \\\"\\\", \\\"nf-name\\\": | -| | | | \\\"Ete_vFWDTvFWSNK_ccc04407_1\\\", \\\"cloudOwner\\\": | -| | | | \\\"CloudOwner\\\", \\\"service_instance_id\\\": | -| | | | \\\"319e60ef-08b1-47aa-ae92-51b97f05e1bc\\\", | -| | | | \\\"vf-module-id\\\": \\\"0dce0e61-9309-449a-8e3e-f001635aaab1\\\", | -| | | | \\\"cloudClli\\\": \\\"clli1\\\", \\\"ipv6-oam-address\\\": \\\"\\\", | -| | | | \\\"vf-module-name\\\": \\\"Vfmodule_Ete_vFWDTvFWSNK_ccc04407_1\\\", | -| | | | \\\"vnfHostName\\\": \\\"Ete_vFWDTvFWSNK_ccc04407_1\\\", \\\"nf-id\\\": | -| | | | (...) | -| | | | \\\"Vfmodule_Ete_vFWDTvFWSNK_ccc04407_1-vfw_private_1_port-6yfzndtyjzfz\\\", | -| | | | \\\"ipv4-addresses\\\": [\\\"192.168.20.100\\\"], \\\"interface-id\\\": | -| | | | \\\"0a1d0300-de02-46e8-99f6-e786f1ba407a\\\", \\\"network-name\\\": | -| | | | \\\"\\\", \\\"ipv6-addresses\\\": []}]}], \\\"nf-type\\\": \\\"vnf\\\"}]}\", | -| | | | \"fixed_ip_address\": \"10.0.210.103\", \"book_name\": | -| | | | \"vpgn/latest/ansible/distributetraffic/site.yml\", | -| | | | \"ne_id\": \"vofwl01pgn4407\"}}", | -| | | | | -+---------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------+------------------------------------------------------------------------------+ - -Exemplary CDT template for Ansible protocol:: - - { - "InventoryNames": "VM", - "PlaybookName": "${()=(book_name)}", - "NodeList": [{ - "vm-info": [{ - "ne_id": "${()=(ne_id)}", - "fixed_ip_address": "${()=(fixed_ip_address)}" - }], - "site": "site", - "vnfc-type": "some-vnfc" - }], - "EnvParameters": { - "ConfigFileName": "../traffic_distribution_config.json", - "vnf_instance": "instance", - }, - "FileParameters": { - "traffic_distribution_config.json": "${()=(file_parameter_content)}" - }, - "Timeout": 3600 - } - -EnvParameters includes protocol specific parameters, here with name of configuration file having additional parameters for Ansible playbook or Chef cookbook. -Distribute Traffic config file can have such parameters like traffic destinations, distribution weights or rollback strategy. - -DistributeTraffic Response -^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The response does not include any payload parameters. - -**Success:** A successful distribute returns a success status code 400 after all traffic has been distributed. - -**Failure:** A failed distribute returns a failure code 401 and the failure message from the Ansible or Chef server in the response payload block. - - -DistributeTrafficCheck ----------------------- - -The Distribute Traffic Check LCM action complements Distribute Traffic LCM action with capabilities to test if destination point -is ready to handle traffic or if anchor point accepts the configuration of destinations for traffic distribution. Finally, -this action can be used to check if destination points handle traffic accordingly with the configuration. - -This command is executed using an Ansible playbook or Chef cookbook. - -Request Structure: - -+--------------------------+--------------------------------------------------------------------+ -| **Target URL** | /restconf/operations/appc-provider-lcm:distribute-traffic-check | -+--------------------------+--------------------------------------------------------------------+ -| **Action** | DistributeTrafficCheck | -+--------------------------+--------------------------------------------------------------------+ -| **Action-identifiers** | vnf-id, vserver-id, vnfc-name | -+--------------------------+--------------------------------------------------------------------+ -| **Payload Parameters** | See below | -+--------------------------+--------------------------------------------------------------------+ -| **Revision History** | New in Dublin | -+--------------------------+--------------------------------------------------------------------+ - -Request Payload Parameters: - -+---------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------+---------------------------------------------------------------+ -| **Parameter** | **Description** | **Required?** | **Example** | -+=================================+==================================================================================================================================================================+=====================+===============================================================+ -| configuration-parameters | A set of instance specific configuration parameters should be specified. If provided, APP-C replaces variables in the configuration template with the | No | "payload": "{\"configuration-parameters\": | -| | values supplied. The parameters are associated with request template defined with CDT | | {\"file_parameter_content\": \"{\\\"destinations\\\": | -| | | | [ | -| | | | {\\\"locationType\\\": \\\"att_aic\\\", | -| | | | \\\"isRehome\\\": \\\"false\\\", | -| | | | \\\"aic_version\\\": \\\"1\\\", | -| | | | \\\"ipv4-oam-address\\\": \\\"\\\", | -| | | | \\\"nf-name\\\": \\\"Ete_vFWDTvFWSNK_ccc04407_1\\\", | -| | | | \\\"cloudOwner\\\": \\\"CloudOwner\\\", | -| | | | \\\"service_instance_id\\\": | -| | | | \\\"319e60ef-08b1-47aa-ae92-51b97f05e1bc\\\", | -| | | | \\\"vf-module-id\\\": | -| | | | \\\"0dce0e61-9309-449a-8e3e-f001635aaab1\\\", | -| | | | \\\"cloudClli\\\": \\\"clli1\\\", | -| | | | \\\"ipv6-oam-address\\\": \\\"\\\", | -| | | | \\\"vf-module-name\\\": | -| | | | \\\"Vfmodule_Ete_vFWDTvFWSNK_ccc04407_1\\\", | -| | | | \\\"vnfHostName\\\": | -| | | | \\\"Ete_vFWDTvFWSNK_ccc04407_1\\\", | -| | | | \\\"nf-id\\\": \\\"909d396b-4d99-4c6a-a59b-abe948873303\\\", | -| | | | (...) | -| | | | \\\"trafficPresence\\\": true}\", | -| | | | \"fixed_ip_address\": \"10.0.110.1\", \"book_name\": | -| | | | \"vfw-sink/latest/ansible/distributetrafficcheck/site.yml\", | -| | | | \"ne_id\": \"vofwl02vfw4407\"}}" | -| | | | | -+---------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------+---------------------------------------------------------------+ - -Exemplary CDT template for Ansible protocol:: - - { - "InventoryNames": "VM", - "PlaybookName": "${()=(book_name)}", - "NodeList": [{ - "vm-info": [{ - "ne_id": "${()=(ne_id)}", - "fixed_ip_address": "${()=(fixed_ip_address)}" - }], - "site": "site", - "vnfc-type": "some-vnfc" - }], - "EnvParameters": { - "ConfigFileName": "../traffic_distribution_config.json", - "vnf_instance": "instance", - }, - "FileParameters": { - "traffic_distribution_config.json": "${()=(file_parameter_content)}" - }, - "Timeout": 3600 - } - -EnvParameters includes protocol specific parameters, here with name of configuration file having additional parameters for Ansible playbook or Chef cookbook. -Distribute Traffic config file can have similar parameters like the one Distribute Traffic action and can have some extra information like the type of check to -be performed. In the payload example there is a trafficPresence parameter that emphasises if the traffic is expected on vFW instance. - -DistributeTrafficCheck Response -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The response does not include any payload parameters. - -**Success:** A successful distribute traffic check returns a success status code 400 when conditions are satisfied. - -**Failure:** A failed check returns a failure code 401 and the failure message from the Ansible or Chef server in the response payload block. - - -DownloadNESw ---------------- - -The DownloadNESw LCM action downloads the target software needed for a software upgrade. - -This command is executed using an Ansible playbook or Chef cookbook. - -Request Structure: - -+--------------------------+------------------------------------------------------------+ -| **Target URL** | /restconf/operations/appc-provider-lcm:download-n-e-sw | -+--------------------------+------------------------------------------------------------+ -| **Action** | DownloadNESw | -+--------------------------+------------------------------------------------------------+ -| **Action-identifiers** | vnf-id | -+--------------------------+------------------------------------------------------------+ -| **Payload Parameters** | See below | -+--------------------------+------------------------------------------------------------+ -| **Revision History** | New in Frankfurt | -+--------------------------+------------------------------------------------------------+ - -Request Payload Parameters: - -+-----------------------+-------------------------------------+---------------------+-----------------------------------------------------------------------------------------------+ -| **Parameter** | **Description** | **Required?** | **Example** | -+=======================+=====================================+=====================+===============================================================================================+ -| swToBeDownloaded | The software to be downloaded | Yes | "payload": | -| | | | "{\"swToBeDownloaded\": \"\\\\'[{\\\\\\\"swLocation\\\\\\\": | -| | | | \\\\\\\"http://192.168.1.10:10080/ran_du_pkg1-v2.zip\\\\\\\"}]\\\\'\"}" | -+-----------------------+-------------------------------------+---------------------+-----------------------------------------------------------------------------------------------+ - -DownloadNESw Response -^^^^^^^^^^^^^^^^^^^^^^^^ - -**Success:** If the DownloadNESw runs successfully, it returns a success status code 400. The response payload contains the results of the downloading. - -Response Payload Parameters: - -+-----------------+-----------------------------+---------------------+------------------------------------------------------------------------------------------------------------------------------+ -| **Parameter** | **Description** | **Required?** | **Example** | -+=================+=============================+=====================+==============================================================================================================================+ -| result | Returns the result | Yes | | -| | of the download-n-e-sw. | | "payload": | -| | Indicates Success or | | "{\\"result\\": \\"Success\\"}” | -| | Failure. | | | -+-----------------+-----------------------------+---------------------+ | -| reason | If not Success, | | | -| | reason contains | | | -| | explanation. | | | -+-----------------+-----------------------------+---------------------+------------------------------------------------------------------------------------------------------------------------------+ - -**Failure:** If a DownloadNESw fails to run, it returns a failure code 401 and the failure reason from the Ansible or Chef server in the response payload block. - - -Evacuate --------- - -Evacuates a specified VM from its current host to another. After a successful evacuate, a rebuild VM is performed if a snapshot is available (and the VM boots from a snapshot). - -The host on which the VM resides needs to be down. - -If the target host is not specified in the request, it will be selected by relying on internal rules to evacuate. The Evacuate action will fail if the specified target host is not UP/ENABLED. - -After Evacuate, the rebuild VM can be disabled by setting the optional `rebuild-vm` parameter to false. - -A successful Evacuate action returns a success response. A failed Evacuate action returns a failure. - -**NOTE:** The command implementation is based on Openstack functionality. For further details, see http://developer.openstack.org/api-ref/compute/. - -+------------------------------+-------------------------------------------------------------------------+ -| **Target URL** | /restconf/operations/appc-provider-lcm:evacuate | -+------------------------------+-------------------------------------------------------------------------+ -| **Action** | Evacuate | -+------------------------------+-------------------------------------------------------------------------+ -| **Action-identifiers** | Vnf-id, vserver-id | -+------------------------------+-------------------------------------------------------------------------+ -| **Payload Parameters** | vm-id, identity-url, tenant-id, rebuild-vm, targethost-id | -+------------------------------+-------------------------------------------------------------------------+ -| **Revision History** | Unchanged in this release. | -+------------------------------+-------------------------------------------------------------------------+ - -| - -+----------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------+---------------------------------------+ -| **Parameter** | **Description** | **Required?** | **Example** | -+======================+==================================================================================================================================================================================+=====================+=======================================+ -| vm-id | The unique identifier (UUID) of the resource. For backwards- compatibility, this can be the self-link URL of the VM. | Yes | "payload": | -| | | | "{\\"vm-id\\": \\" | -| | | | \\", | -| | | | \\"identity-url\\": | -| | | | \\"\\", | -| | | | \\"tenant-id\\": \\" | -| | | | \\", | -| | | | \\"rebuild-vm\\": \\"false\\", | -| | | | \\"targethost-id\\": | -| | | | \\"nodeblade7\\"}" | -+----------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------+ | -| identity-url | The identity URL used to access the resource | Yes | | -+----------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------+ | -| tenant-id | The id of the provider tenant that owns the resource | Yes | | -+----------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------+ | -| rebuild- vm | A boolean flag indicating if a Rebuild is to be performed after an Evacuate. The default action is to do a Rebuild. It can be switched off by setting the flag to "false". | No | | -+----------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------+ | -| targethost- id | A target hostname indicating the host the VM is evacuated to. By default, the cloud determines the target host. | No | | -+----------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------+---------------------------------------+ - -Evacuate Response: -^^^^^^^^^^^^^^^^^^ -**Success:** A successful Evacuate returns a success status code 400. -**Failure:** A failed Evacuate returns a failure code 401 and the failure message. - - -GetConfig ---------- - -GetConfig LCM action for the MVM VNF types using the GetConfig playbook -to retrieve the current config. This is limited to Ansible. - -A successful GetConfig request returns a success response. - -A failed GetConfig action returns a failure response code and the -specific failure message in the response block. - - -====================== ================================================= -**Target URL** /restconf/operations/appc-provider-lcm: GetConfig -====================== ================================================= -**Action** GetConfig -**Action-Identifiers** vnf-id -**Payload Parameters** See table -**Revision History** New in Frankfurt -====================== ================================================= - -========================= ========================================================================================================= ============= ====================================================================================================== -**Payload Parameter** **Description** **Required?** **Example** -========================= ========================================================================================================= ============= ====================================================================================================== -request- parameters Not used. This request is limited to Ansible only. No "payload": "{\"configuration-parameters\":{\"vnf_name\":\"test\",\"operations_timeout\":\"3600\"}}" or - - "payload": "{}" -configuration- parameters A set of instance specific configuration parameters should be specified, as required by Ansible playbook. No -========================= ========================================================================================================= ============= ====================================================================================================== - -GetConfig Response: -~~~~~~~~~~~~~~~~~~~ - -Success: A successful GetConfig returns a success status code 400. - -Failure: A failed GetConfig returns a failure code 401 and the failure -message. - - -HealthCheck ------------ - -This command runs a VNF health check and returns the result. - -The VNF level HealthCheck is a check over the entire scope of the VNF. The VNF must be 100% healthy, ready to take requests and provide services, with all VNF required capabilities ready to provide services and with all active and standby resources fully ready with no open MINOR, MAJOR or CRITICAL alarms. - - -+------------------------------+-----------------------------------------------------------+ -| **Target URL** | /restconf/operations/appc-provider-lcm:health-check | -+------------------------------+-----------------------------------------------------------+ -| **Action** | HealthCheck | -+------------------------------+-----------------------------------------------------------+ -| **Action-Identifiers** | Vnf-id | -+------------------------------+-----------------------------------------------------------+ -| **Payload Parameters** | See below | -+------------------------------+-----------------------------------------------------------+ -| **Revision History** | Unchanged in this release | -+------------------------------+-----------------------------------------------------------+ - - -Request Payload Parameters: - -+---------------------+-----------------------------------+---------------------+-------------------------------------+ -| **Parameter** | **Description** | **Required?** | **Example** | -+=====================+===================================+=====================+=====================================+ -| request-parameters | host-ip-address - | No | "payload": | -| | Required only if REST | | "{\\"request-parameters \\": | -| | service. This is the ip | | "{\\"host-ip-address\\": | -| | address associated with the | | \\"10.222.22.2\\" }" | -| | VM running the REST | | | -| | service. | | | -+---------------------+-----------------------------------+---------------------+-------------------------------------+ - - -HealthCheck Response -^^^^^^^^^^^^^^^^^^^^ - -**Success:** The HealthCheck returns a 400 success message if the test completes. A JSON payload is returned indicating state (healthy, unhealthy), scope identifier, time-stamp and one or more blocks containing info and fault information. - - Examples:: - - { - "identifier": "scope represented", - "state": "healthy", - "time": "01-01-1000:0000" - - } - - { - "identifier": "scope represented", - "state": "unhealthy", - {[ - "info": "System threshold exceeded details", - "fault": - { - "cpuOverall": 0.80, - "cpuThreshold": 0.45 - } - ]}, - "time": "01-01-1000:0000" - } - -**Failure:** If the VNF is unable to run the HealthCheck. APP-C returns the error code 401 and the http error message. - -LicenseManagement ------------------ - -For LicenseManagement LCM action, invoke the LicenseManagement playbook. -This is limited to Ansible. - -A successful LicenseManagement request returns a success response. - -A failed LicenseManagement action returns a failure response code and -the specific failure message in the response block. - - -====================== ======================================================== -**Target URL** /restconf/operations/appc-provider-lcm:LicenseManagement -====================== ======================================================== -**Action** LicenseManagement -**Action-Identifiers** vnf-id -**Payload Parameters** See below -**Revision History** New in Frankfurt -====================== ======================================================== - -========================= ========================================================================================================= ============= ====================================================================================================================== -**Payload Parameter** **Description** **Required?** **Example** -========================= ========================================================================================================= ============= ====================================================================================================================== -request- parameters Not used. This request is limited to Ansible only. No "action": "LicenseManagement", - - "action-identifiers": { - - "vnf-id": "rarf9901v" - - }, - - "payload": "{\"configuration-parameters\":{\"vnf_name\":\"rarf9901v\",\"license_action\":\"update\"}}" --- - - license_action can have any of these values ={ upload \| add \| install \| update \| renew \| delete \| revoke \| … }: -configuration- parameters A set of instance specific configuration parameters should be specified, as required by Ansible playbook. No -========================= ========================================================================================================= ============= ====================================================================================================================== - -LicenseManagement Response\ **:** -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Success: A successful LicenseManagement returns a success status code -400. - -Failure: A failed LicenseManagement returns a failure code 401 and the -failure message. - - - - -Lock ----- - -Use the Lock command to ensure exclusive access during a series of critical LCM commands. - -The Lock action will return a successful result if the VNF is not already locked or if it was locked with the same request-id, otherwise the action returns a response with a reject status code. - -Lock is a command intended for APPC and does not execute an actual VNF command. Instead, lock will ensure that ONAP is granted exclusive access to the VNF. - -When a VNF is locked, any subsequent sequential commands with same request-id will be accepted. Commands associated with other request-ids will be rejected. - -APPC locks the target VNF during any VNF command processing. If a lock action is then requested on that VNF, it will be rejected because the VNF was already locked, even though no actual lock command was explicitly invoked. - -The lock automatically clears after 900 seconds (15 minutes). This 900 second value can be adjusted in the properties file - -+------------------------------+---------------------------------------------------+ -| **Target URL** | /restconf/operations/appc-provider-lcm:lock | -+------------------------------+---------------------------------------------------+ -| **Action** | Lock | -+------------------------------+---------------------------------------------------+ -| **Action-Identifier** | Vnf-id | -+------------------------------+---------------------------------------------------+ -| **Payload Parameters** | None | -+------------------------------+---------------------------------------------------+ -| **Revision History** | Unchanged in this release. | -+------------------------------+---------------------------------------------------+ - -Lock Response -^^^^^^^^^^^^^ - -The Lock returns a 400 Success response if the Lock is successfully applied. - -The Lock returns a 401 Failure response with the failure message if the Lock is not successful. - - -Migrate -------- - -Migrates a running target VM from its current host to another. - -A destination node will be selected by relying on internal rules to migrate. Migrate calls a command in order to perform the operation. - -Migrate suspends the guest virtual machine, and moves an image of the guest virtual machine's disk to the destination host physical machine. The guest virtual machine is then resumed on the destination host physical machine and the disk storage that it used on the source host physical machine is freed. - -The migrate action will leave the VM in the same Openstack state the VM had been in prior to the migrate action. If a VM was stopped before migration, a separate VM-level restart command would be needed to restart the VM after migration. - - -**NOTE:** The command implementation is based on Openstack functionality. For further details, see http://developer.openstack.org/api-ref/compute/. - - -+--------------------------------+-----------------------------------------------------------------------------------------------+ -| **Input Block** | api-ver should be set to 2.00 for current version of Migrate | -+--------------------------------+-----------------------------------------------------------------------------------------------+ -| **Target URL** | /restconf/operations/appc-provider-lcm:migrate | -+--------------------------------+-----------------------------------------------------------------------------------------------+ -| **Action** | Migrate | -+--------------------------------+-----------------------------------------------------------------------------------------------+ -| **Action-Identifiers** | Vnf-id, vserver-id | -+--------------------------------+-----------------------------------------------------------------------------------------------+ -| **Payload Parameters** | vm-id, identity-url, tenant-id | -+--------------------------------+-----------------------------------------------------------------------------------------------+ -| **Revision History** | Unchanged in this release. | -+--------------------------------+-----------------------------------------------------------------------------------------------+ - -Payload Parameters - -+---------------------+-------------------------------------------------------------------------+---------------------+-----------------------------------------------+ -| **Parameter** | **Description** | **Required?** | **Example** | -+=====================+=========================================================================+=====================+===============================================+ -| vm-id | The unique identifier (UUID) of | Yes | | -| | the resource. For backwards- compatibility, this can be the self- | | | -| | link URL of the VM. | | "payload": | -| | | | "{\\"vm-id\\": \\"\\", | -| | | | \\"identity-url\\": | -| | | | \\"\\", | -+---------------------+-------------------------------------------------------------------------+---------------------+ \\"tenant-id\\": \\"\\"}" | -| identity- url | The identity url used to access the resource | Yes | | -| | | | | -+---------------------+-------------------------------------------------------------------------+---------------------+ | -| tenant-id | The id of the provider tenant that owns the resource | Yes | | -+---------------------+-------------------------------------------------------------------------+---------------------+-----------------------------------------------+ - - -Migrate Response -^^^^^^^^^^^^^^^^ - -**Success:** A successful Migrate returns a success status code 400. - -**Failure:** A failed Migrate returns a failure code 401 and the failure message. - - -PostEvacuate -------------- - -PostEvacuate LCM action using the PostEvacuate playbook. This is limited -to Ansible. - -A successful PostEvacuate request returns a success response. - -A failed PostEvacuate action returns a failure response code and the -specific failure message in the response block. - -====================== ==================================================== -**Target URL** /restconf/operations/appc-provider-lcm: PostEvacuate -====================== ==================================================== -**Action** PostEvacuate -**Action-Identifiers** vnf-id -**Payload Parameters** See table -**Revision History** New in Frankfurt -====================== ==================================================== - -========================= ========================================================================================================= ============= ===================================================================================================== -**Payload Parameter** **Description** **Required?** **Example** -========================= ========================================================================================================= ============= ===================================================================================================== -request- parameters Not used. This request is limited to Ansible only. No "payload" : "{\"configuration-parameters\":{\"vnf_name\":\"xxxxxx\",\"vm_name\":\"135.21.178.100\"}}" -configuration- parameters A set of instance specific configuration parameters should be specified, as required by Ansible playbook. No -========================= ========================================================================================================= ============= ===================================================================================================== - -PostEvacuate Response: -~~~~~~~~~~~~~~~~~~~~~~ - -Success: A successful PostEvacuate returns a success status code 400. - -Failure: A failed PostEvacuate returns a failure code 401 and the -failure message. - - -PostMigrate ------------ - -PostMigrate LCM action using the PostMigrate playbook. This is limited -to Ansible. - -A successful PostMigrate request returns a success response. - -A failed PostMigrate action returns a failure response code and the -specific failure message in the response block. - - -====================== =================================================== -**Target URL** /restconf/operations/appc-provider-lcm: PostMigrate -====================== =================================================== -**Action** PostMigrate -**Action-Identifiers** vnf-id -**Payload Parameters** See below -**Revision History** New in Frankfurt -====================== =================================================== - -========================= ========================================================================================================= ============= ===================================================================================================== -**Payload Parameter** **Description** **Required?** **Example** -========================= ========================================================================================================= ============= ===================================================================================================== -request- parameters Not used. This request is limited to Ansible only. No "payload" : "{\"configuration-parameters\":{\"vnf_name\":\"xxxxxx\",\"vm_name\":\"135.21.178.100\"}}" -configuration- parameters A set of instance specific configuration parameters should be specified, as required by Ansible playbook. No -========================= ========================================================================================================= ============= ===================================================================================================== - -PostMigrate Response: -~~~~~~~~~~~~~~~~~~~~~ - -Success: A successful PostMigrate returns a success status code 400. - -Failure: A failed PostMigrate returns a failure code 401 and the failure -message. - - - -PostRebuild ------------ - -PostRebuild LCM action using the PostRebuild playbook. This is limited -to Ansible. - -A successful PostRebuild request returns a success response. - -A failed PostRebuild action returns a failure response code and the -specific failure message in the response block. - -====================== =================================================== -**Target URL** /restconf/operations/appc-provider-lcm: PostRebuild -====================== =================================================== -**Action** PostRebuild -**Action-Identifiers** vnf-id -**Payload Parameters** See table -**Revision History** New in Frankfurt -====================== =================================================== - -========================= ========================================================================================================= ============= ===================================================================================================== -**Payload Parameter** **Description** **Required?** **Example** -========================= ========================================================================================================= ============= ===================================================================================================== -request- parameters Not used. This request is limited to Ansible only. No "payload" : "{\"configuration-parameters\":{\"vnf_name\":\"xxxxxx\",\"vm_name\":\"135.21.178.100\"}}" -configuration- parameters A set of instance specific configuration parameters should be specified, as required by Ansible playbook. No -========================= ========================================================================================================= ============= ===================================================================================================== - -PostRebuild Response: -~~~~~~~~~~~~~~~~~~~~~ - -Success: A successful PostRebuild returns a success status code 400. - -Failure: A failed PostRebuild returns a failure code 401 and the failure -message. - - -PreConfig ---------- - -PreConfig LCM action for the MVM VNF types using the PreConfigure -playbook. This is limited to Ansible. - -A successful PreConfig request returns a success response. - -A failed PreConfig action returns a failure response code and the -specific failure message in the response block. - - -====================== ================================================= -**Target URL** /restconf/operations/appc-provider-lcm: PreConfig -====================== ================================================= -**Action** PreConfig -**Action-Identifiers** vnf-id -**Payload Parameters** See table -**Revision History** New in Frankfurt -====================== ================================================= - -========================= ========================================================================================================= ============= ====================================================================================================== -**Payload Parameter** **Description** **Required?** **Example** -========================= ========================================================================================================= ============= ====================================================================================================== -request- parameters Not used. This request is limited to Ansible only. No "payload": "{\"configuration-parameters\":{\"vnf_name\":\"test\",\"operations_timeout\":\"3600\"}}" or - - "payload": "{}" -configuration- parameters A set of instance specific configuration parameters should be specified, as required by Ansible playbook. No -========================= ========================================================================================================= ============= ====================================================================================================== - -PreConfig Response: -------------------- - -Success: A successful PreConfig returns a success status code 400. - -Failure: A failed PreConfig returns a failure code 401 and the failure -message. - -PreEvacuate ------------- - -PreEvacuate LCM action using the PreEvacuate playbook. This is limited -to Ansible. - -A successful PreEvacuate request returns a success response. - -A failed PreEvacuate action returns a failure response code and the -specific failure message in the response block. - - -====================== =================================================== -**Target URL** /restconf/operations/appc-provider-lcm: PreEvacuate -====================== =================================================== -**Action** PreEvacuate -**Action-Identifiers** vnf-id -**Payload Parameters** See table -**Revision History** New in Frankfurt -====================== =================================================== - -========================= ========================================================================================================= ============= ===================================================================================================== -**Payload Parameter** **Description** **Required?** **Example** -========================= ========================================================================================================= ============= ===================================================================================================== -request- parameters Not used. This request is limited to Ansible only. No "payload" : "{\"configuration-parameters\":{\"vnf_name\":\"xxxxxx\",\"vm_name\":\"135.21.178.100\"}}" -configuration- parameters A set of instance specific configuration parameters should be specified, as required by Ansible playbook. No -========================= ========================================================================================================= ============= ===================================================================================================== - -PreEvacuate Response: -~~~~~~~~~~~~~~~~~~~~~ - -Success: A successful PreEvacuate returns a success status code 400. - -Failure: A failed PreEvacuate returns a failure code 401 and the failure -message. - -PreMigrate ----------- - -PreMigrate LCM action using the PreMigrate playbook. This is limited to -Ansible. - -A successful PreMigrate request returns a success response. - -A failed PreMigrate action returns a failure response code and the -specific failure message in the response block. - -====================== ================================================== -**Target URL** /restconf/operations/appc-provider-lcm: PreMigrate -====================== ================================================== -**Action** PreMigrate -**Action-Identifiers** vnf-id -**Payload Parameters** See table -**Revision History** New in Frankfurt -====================== ================================================== - -========================= ========================================================================================================= ============= ===================================================================================================== -**Payload Parameter** **Description** **Required?** **Example** -========================= ========================================================================================================= ============= ===================================================================================================== -request- parameters Not used. This request is limited to Ansible only. No "payload" : "{\"configuration-parameters\":{\"vnf_name\":\"xxxxxx\",\"vm_name\":\"135.21.178.100\"}}" -configuration- parameters A set of instance specific configuration parameters should be specified, as required by Ansible playbook. No -========================= ========================================================================================================= ============= ===================================================================================================== - -PreMigrate Response: -~~~~~~~~~~~~~~~~~~~~ - -Success: A successful PreMigrate returns a success status code 400. - -Failure: A failed PreMigrate returns a failure code 401 and the failure -message. - - -PreRebuild ----------- - -PreRebuild LCM action using the PreRebuild playbook. This is limited to -Ansible. - -A successful PreRebuild request returns a success response. - -A failed PreRebuild action returns a failure response code and the -specific failure message in the response block. - - -====================== ================================================== -**Target URL** /restconf/operations/appc-provider-lcm: PreRebuild -====================== ================================================== -**Action** PreRebuild -**Action-Identifiers** vnf-id -**Payload Parameters** See table -**Revision History** New in Frankfurt -====================== ================================================== - -========================= ========================================================================================================= ============= ===================================================================================================== -**Payload Parameter** **Description** **Required?** **Example** -========================= ========================================================================================================= ============= ===================================================================================================== -request- parameters Not used. This request is limited to Ansible only. No "payload" : "{\"configuration-parameters\":{\"vnf_name\":\"xxxxxx\",\"vm_name\":\"135.21.178.100\"}}" -configuration- parameters A set of instance specific configuration parameters should be specified, as required by Ansible playbook. No -========================= ========================================================================================================= ============= ===================================================================================================== - -PreRebuild Response: -~~~~~~~~~~~~~~~~~~~~ - -Success: A successful PreRebuild returns a success status code 400. - -Failure: A failed PreRebuild returns a failure code 401 and the failure -message. - - -Provisioning ------------- - -For Provisioning LCM action, invoke the Provisioning playbook. This is -limited to Ansible. - -A successful Provisioning request returns a success response. - -A failed Provisioning action returns a failure response code and the -specific failure message in the response block. - - -====================== =================================================== -**Target URL** /restconf/operations/appc-provider-lcm:Provisioning -====================== =================================================== -**Action** Provisioning -**Action-Identifiers** vnf-id -**Payload Parameters** See table -**Revision History** New in Frankfurt -====================== =================================================== - -========================= ========================================================================================================= ============= ========================= -**Payload Parameter** **Description** **Required?** **Example** -========================= ========================================================================================================= ============= ========================= -request- parameters Not used. This request is limited to Ansible only. No "action": "Provisioning", - - "action-identifiers": { - - "vnf-id": "rarf9901v" - - }, - - "payload": "{}" -configuration- parameters A set of instance specific configuration parameters should be specified, as required by Ansible playbook. No -========================= ========================================================================================================= ============= ========================= - -Provisioning Response\ **:** -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Success: A successful Provisioning returns a success status code 400. - -Failure: A failed Provisioning returns a failure code 401 and the -failure message. - - - -QuiesceTraffic --------------- - -The QuiesceTraffic LCM action gracefully stops the traffic on the VNF (i.e., no service interruption for traffic in progress). All application processes are assumed to be running but no traffic is being processed. - -This command is executed using an Ansible playbook or Chef cookbook. - -Request Structure: - -+--------------------------+----------------------------------------------------------+ -| **Target URL** | /restconf/operations/appc-provider-lcm:quiesce-traffic | -+--------------------------+----------------------------------------------------------+ -| **Action** | QuiesceTraffic | -+--------------------------+----------------------------------------------------------+ -| **Action-identifiers** | vnf-id | -+--------------------------+----------------------------------------------------------+ -| **Payload Parameters** | operations-timeout | -+--------------------------+----------------------------------------------------------+ -| **Revision History** | New in Beijing | -+--------------------------+----------------------------------------------------------+ - -Request Payload Parameters: - -+-----------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------+------------------------------------------------+ -| **Parameter** | **Description** | **Required?** | **Example** | -+=======================+======================================================================================================================================================================================================+=====================+================================================+ -| operations-timeout | This is the maximum time in seconds that the command will run before APPC returns a timeout error. If the APPC template has a lower timeout value, the APPC template timeout value is applied. | Yes | "payload": | -| | | | "{\\"operations-timeout\\": \\"3600\\"}” | -+-----------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------+------------------------------------------------+ - -QuiesceTraffic Response -^^^^^^^^^^^^^^^^^^^^^^^ - -The response does not include any payload parameters. - -**Success:** A successful quiesce returns a success status code 400 after all traffic has been quiesced. - - If a quiesce command is executed and the traffic has been previously quiesced, it should return a success status. - -**Failure:** A failed quiesce returns a failure code 401 and the failure message from the Ansible or Chef server in the response payload block. - - A specific error message is returned if there is a timeout error. - -Reboot -------- - -The Reboot is used to reboot a VM. - - -There are two types supported: HARD and SOFT. A SOFT reboot attempts a graceful shutdown and restart of the server. A HARD reboot attempts a forced shutdown and restart of the server. The HARD reboot corresponds to the power cycles of the server. - -**NOTE:** The command implementation is based on OpenStack functionality. For further details, see http://developer.openstack.org/api-ref/compute/. - -+------------------------------+-----------------------------------------------------------------------------------------------+ -| **Input Block** | api-ver should be set to 2.00 for current version of Reboot | -+------------------------------+-----------------------------------------------------------------------------------------------+ -| **Target URL** | /restconf/operations/appc-provider-lcm:reboot | -+------------------------------+-----------------------------------------------------------------------------------------------+ -| **Action** | Reboot | -+------------------------------+-----------------------------------------------------------------------------------------------+ -| **Action-identifiers** | Vnf-id, vserver-id | -+------------------------------+-----------------------------------------------------------------------------------------------+ -| **Payload Parameters** | See table below | -+------------------------------+-----------------------------------------------------------------------------------------------+ -| **Revision History** | New in R3 release. | -+------------------------------+-----------------------------------------------------------------------------------------------+ - -Payload Parameters - -+-----------------+-----------------------------------------------+-----------------+-----------------------------------------+ -| **Parameter** | **Description** | **Required?** | **Example** | -+=================+===============================================+=================+=========================================+ -| type | The type of reboot. Values are | No | | -| | HARD and SOFT. If not | | | -| | specified, SOFT reboot is | | "payload": | -| | performed. | | "{\\"type\\": \\"HARD\\", | -| | | | \\"vm-id\\": \\"\\", | -| | | | \\"identity-url\\": | -| | | | \\"\\" | -| | | | }" | -+-----------------+-----------------------------------------------+-----------------+ | -| vm-id | The unique identifier (UUID) of | Yes | | -| | the resource. For backwards- | | | -| | compatibility, this can be the self- | | | -| | link URL of the VM. | | | -| | | | | -| | | | | -| | | | | -| | | | | -+-----------------+-----------------------------------------------+-----------------+ | -| identity-url | The identity url used to access the | Yes | | -| | resource. | | | -+-----------------+-----------------------------------------------+-----------------+-----------------------------------------+ - -Reboot Response -^^^^^^^^^^^^^^^ - -**Success:** A successful Rebuild returns a success status code 400. - -**Failure:** A failed Rebuild returns a failure code 401 and the failure message. - -Rebuild -------- - -Recreates a target VM instance to a known, stable state. - -Rebuild calls an OpenStack command immediately and therefore does not expect any prerequisite operations to be performed, such as shutting off a VM. - -Rebuild VM uses the snapshot provided by the snapshot-id (if provided). If not provided, the latest snapshot is used. If there are no snapshots, it uses the (original) Glance image. - -APPC rejects a rebuild request if it determines the VM boots from a Cinder Volume - - -**NOTE:** The command implementation is based on Openstack functionality. For further details, see http://developer.openstack.org/api-ref/compute/. - - -+------------------------------+-----------------------------------------------------------------------------------------------+ -| **Input Block** | api-ver should be set to 2.00 for current version of Rebuild | -+------------------------------+-----------------------------------------------------------------------------------------------+ -| **Target URL** | /restconf/operations/appc-provider-lcm:rebuild | -+------------------------------+-----------------------------------------------------------------------------------------------+ -| **Action** | Rebuild | -+------------------------------+-----------------------------------------------------------------------------------------------+ -| **Action-identifiers** | Vnf-id, vserver-id | -+------------------------------+-----------------------------------------------------------------------------------------------+ -| **Payload Parameters** | See table below | -+------------------------------+-----------------------------------------------------------------------------------------------+ -| **Revision History** | Unchanged in this release. | -+------------------------------+-----------------------------------------------------------------------------------------------+ - - -Payload Parameters - -+-----------------+-----------------------------------------------+-----------------+-----------------------------------------+ -| **Parameter** | **Description** | **Required?** | **Example** | -+=================+===============================================+=================+=========================================+ -| vm-id | The unique identifier (UUID) of | Yes | | -| | the resource. For backwards- | | | -| | compatibility, this can be the self- | | "payload": | -| | link URL of the VM. | | "{\\"vm-id\\": \\" | -| | | | \\", | -| | | | \\"identity-url\\": | -| | | | \\"\\", | -| | | | \\"tenant-id\\": \\"\\"}" | -+-----------------+-----------------------------------------------+-----------------+ \\"snapshot-id\\": \\"\\" | -| identity- url | The identity url used to access the | Yes | }" | -| | resource. | | | -+-----------------+-----------------------------------------------+-----------------+ | -| tenant-id | The id of the provider tenant that owns | Yes | | -| | the resource. | | | -+-----------------+-----------------------------------------------+-----------------+ | -| snapshot-id | The snapshot-id of a previously saved image. | No | | -+-----------------+-----------------------------------------------+-----------------+-----------------------------------------+ - -Rebuild Response -^^^^^^^^^^^^^^^^ - -**Success:** A successful Rebuild returns a success status code 400. - -**Failure:** A failed Rebuild returns a failure code 401 and the failure message. - -Restart -------- - -Use the Restart command to restart a VM. - -+------------------------------+-----------------------------------------------------------------------------------------------------------------+ -| **Input Block** | api-ver should be set to 2.00 for current version of Restart | -+------------------------------+-----------------------------------------------------------------------------------------------------------------+ -| **Target URL** | /restconf/operations/appc-provider-lcm:restart | -+------------------------------+-----------------------------------------------------------------------------------------------------------------+ -| **Action** | Restart | -+------------------------------+-----------------------------------------------------------------------------------------------------------------+ -| **Action-identifiers** | vnf-id and vserver-id are required | -+------------------------------+-----------------------------------------------------------------------------------------------------------------+ -| **Payload Parameters** | See table below | -+------------------------------+-----------------------------------------------------------------------------------------------------------------+ -| **Revision History** | Unchanged in this release | -+------------------------------+-----------------------------------------------------------------------------------------------------------------+ - -Payload Parameters for **VM Restart** - -+---------------------+-------------------------------------------------------------------------+---------------------+------------------------------------+ -| **Parameter** | **Description** | **Required?** | **Example** | -+=====================+=========================================================================+=====================+====================================+ -| vm-id | The unique identifier (UUID) of | Yes | | -| | the resource. For backwards- compatibility, this can be the self- | | | -| | link URL of the VM | | "payload": | -| | | | "{\\"vm-id\\": \\"\\", | -| | | | \\"identity-url\\": | -+---------------------+-------------------------------------------------------------------------+---------------------+ \\"\\", | -| identity- url | The identity url used to access the resource | No | \\"tenant-id\\": \\"\\"}" | -+---------------------+-------------------------------------------------------------------------+---------------------+ | -| tenant-id | The id of the provider tenant that owns the resource | No | | -+---------------------+-------------------------------------------------------------------------+---------------------+------------------------------------+ - -ResumeTraffic -------------- - -The ResumeTraffic LCM action resumes processing traffic on a VNF that has been previously quiesced. - -This command is executed using an Ansible playbook or Chef cookbook. - -Request Structure: The payload does not have any parameters. - -+--------------------------+---------------------------------------------------------+ -| **Target URL** | /restconf/operations/appc-provider-lcm:resume-traffic | -+--------------------------+---------------------------------------------------------+ -| **Action** | ResumeTraffic | -+--------------------------+---------------------------------------------------------+ -| **Action-identifiers** | vnf-id | -+--------------------------+---------------------------------------------------------+ -| **Payload Parameters** | | -+--------------------------+---------------------------------------------------------+ -| **Revision History** | New in Beijing | -+--------------------------+---------------------------------------------------------+ - -ResumeTraffic Response -^^^^^^^^^^^^^^^^^^^^^^ - -**Success:** A successful ResumeTraffic returns a success status code 400 after traffic has been resumed. - -If a ResumeTraffic command is executed and the traffic is currently being processed, it should return a success status - -**Failure:** A failed ResumeTraffic returns a failure code 401 and the failure message from the Ansible or Chef server in the response payload block. - - -Snapshot --------- - -Creates a snapshot of a VM. - -The Snapshot command returns a customized response containing a reference to the newly created snapshot instance if the action is successful. - -This command can be applied to a VM in any VNF type. The only restriction is that the particular VNF should be built based on the generic heat stack. - -Note: Snapshot is not reliable unless the VM is in a stopped, paused, or quiesced (no traffic being processed) status. It is up to the caller to ensure that the VM is in one of these states. - -**NOTE:** The command implementation is based on Openstack functionality. For further details, see http://developer.openstack.org/api-ref/compute/. - -+------------------------------+-----------------------------------------------------------------------------------------------------+ -| **Target URL** | /restconf/operations/appc-provider-lcm:snapshot | -+------------------------------+-----------------------------------------------------------------------------------------------------+ -| **Action** | Snapshot | -+------------------------------+-----------------------------------------------------------------------------------------------------+ -| **Action-identifiers** | vnf-id, vserver-id | -+------------------------------+-----------------------------------------------------------------------------------------------------+ -| **Payload Parameters** | vm-id, identity-url, tenant-id | -+------------------------------+-----------------------------------------------------------------------------------------------------+ -| **Revision History** | Unchanged in this release. | -+------------------------------+-----------------------------------------------------------------------------------------------------+ - -Payload Parameters - -+---------------------+-------------------------------------------------------------------------+---------------------+----------------------------------------+ -| **Parameter** | **Description** | **Required?** | **Example** | -+=====================+=========================================================================+=====================+========================================+ -| vm-id | The self-link URL of the VM | Yes | | -| | | | "payload": | -| | | | "{\\"vm-id\\": \\"\\", | -| | | | \\"identity-url\\": | -| | | | \\"\\", | -| | | | \\"tenant-id\\":\\"\\"}"| -+---------------------+-------------------------------------------------------------------------+---------------------+ | -| identity- url | The identity url used to access the resource | No | | -| | | | | -+---------------------+-------------------------------------------------------------------------+---------------------+ | -| tenant-id | The id of the provider tenant that owns the resource | No | | -+---------------------+-------------------------------------------------------------------------+---------------------+----------------------------------------+ - -Snapshot Response -^^^^^^^^^^^^^^^^^ - -The Snapshot command returns an extended version of the LCM response. - -The Snapshot response conforms to the standard response format. - - -Start ------ - -Use the Start command to start a VM that is stopped. - -**NOTE:** The command implementation is based on Openstack functionality. For further details, see http://developer.openstack.org/api-ref/compute/. - -+------------------------------+--------------------------------------------------------------------------------------------------------------------------------+ -| **Target URL** | /restconf/operations/appc-provider-lcm:start | -+------------------------------+--------------------------------------------------------------------------------------------------------------------------------+ -| **Action** | Start | -+------------------------------+--------------------------------------------------------------------------------------------------------------------------------+ -| **Action-identifiers** | vnf-id and vserver-id are required | -+------------------------------+--------------------------------------------------------------------------------------------------------------------------------+ -| **Payload Parameters** | See table below | -+------------------------------+--------------------------------------------------------------------------------------------------------------------------------+ -| **Revision History** | Unchanged in this release | -+------------------------------+--------------------------------------------------------------------------------------------------------------------------------+ - -Payload Parameters - -+-----------------+-----------------------------------------------+-----------------+-----------------------------------------+ -| **Parameter** | **Description** | **Required?** | **Example** | -+=================+===============================================+=================+=========================================+ -| vm-id | The unique identifier (UUID) of | Yes | | -| | the resource. For backwards- | | "payload": | -| | compatibility, this can be the self- | | "{\\"vm-id\\": \\" | -| | link URL of the VM. | | \\", | -| | | | \\"identity-url\\": | -| | | | \\"\\", | -| | | | \\"tenant-id\\": \\"\\"}" | -+-----------------+-----------------------------------------------+-----------------+-----------------------------------------+ -| identity- url | The identity url used to access the | No | | -| | resource | | | -+-----------------+-----------------------------------------------+-----------------+-----------------------------------------+ -| tenant-id | The id of the provider tenant that owns | No | | -| | the resource | | | -+-----------------+-----------------------------------------------+-----------------+-----------------------------------------+ - - -StartApplication ----------------- - -Starts the VNF application, if needed, after a VM is instantiated/configured or after VM start or restart. Supported using Chef cookbook or Ansible playbook only. - -A successful StartApplication request returns a success response. - -A failed StartApplication action returns a failure response code and the specific failure message in the response block. - -+------------------------------+---------------------------------------------------------------+ -| **Target URL** | /restconf/operations/appc-provider-lcm:start-application | -+------------------------------+---------------------------------------------------------------+ -| **Action** | StartApplication | -+------------------------------+---------------------------------------------------------------+ -| **Action-Identifiers** | Vnf-id | -+------------------------------+---------------------------------------------------------------+ -| **Payload Parameters** | See table below | -+------------------------------+---------------------------------------------------------------+ -| **Revision History** | Unchanged in this release. | -+------------------------------+---------------------------------------------------------------+ - -| - -+---------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------+-----------------------------------------------------------------+ -| **Payload Parameter** | **Description** | **Required?** | **Example** | -+=================================+====================================================================================================================================================================================+=====================+=================================================================+ -| | | | "payload": | -| configuration- parameters | A set of instance specific configuration parameters should be specified, as required by the Chef cookbook or Ansible playbook. | No | "{\\"configuration- parameters\\": {\\"\\"} | -+---------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------+-----------------------------------------------------------------+ - -StartApplication Response -^^^^^^^^^^^^^^^^^^^^^^^^^ - -The StartApplication response returns an indication of success or failure of the request. - -StartTraffic ------------- - -For StartTraffic LCM action, invoke the StartTraffic playbook. This is -limited to Ansible. - -A successful StartTraffic request returns a success response. - -A failed StartTraffic action returns a failure response code and the -specific failure message in the response block. - - -====================== =================================================== -**Target URL** /restconf/operations/appc-provider-lcm:StartTraffic -====================== =================================================== -**Action** StartTraffic -**Action-Identifiers** vnf-id -**Payload Parameters** See table -**Revision History** New in Frankfurt -====================== =================================================== - -========================= ========================================================================================================= ============= ========================= -**Payload Parameter** **Description** **Required?** **Example** -========================= ========================================================================================================= ============= ========================= -request- parameters Not used. This request is limited to Ansible only. No "action": "StartTraffic", - - "action-identifiers": { - - "vnf-id": "rarf9901v" - - }, - - "payload": "{}" -configuration- parameters A set of instance specific configuration parameters should be specified, as required by Ansible playbook. No -========================= ========================================================================================================= ============= ========================= - -StartTraffic Response\ **:** -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Success: A successful StartTraffic returns a success status code 400. - -Failure: A failed StartTraffic returns a failure code 401 and the -failure message. - - - -StatusTraffic -------------- - -For StatusTraffic LCM action, invoke the StatusTraffic playbook. This is -limited to Ansible. - -A successful StatusTraffic request returns a success response. - -A failed StatusTraffic action returns a failure response code and the -specific failure message in the response block. - -====================== ==================================================== -**Target URL** /restconf/operations/appc-provider-lcm:StatusTraffic -====================== ==================================================== -**Action** StatusTraffic -**Action-Identifiers** vnf-id -**Payload Parameters** See table -**Revision History** New in Frankfurt -====================== ==================================================== - -========================= ========================================================================================================= ============= ========================== -**Payload Parameter** **Description** **Required?** **Example** -========================= ========================================================================================================= ============= ========================== -request- parameters Not used. This request is limited to Ansible only. No "action": "StatusTraffic", - - "action-identifiers": { - - "vnf-id": "rarf9901v" - - }, - - "payload": "{}" -configuration- parameters A set of instance specific configuration parameters should be specified, as required by Ansible playbook. No -========================= ========================================================================================================= ============= ========================== - -StatusTraffic Response\ **:** -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Success: A successful StatusTraffic returns a success status code 400. - -Failure: A failed StatusTraffic returns a failure code 401 and the -failure message. - - -Stop ----- - -Use the Stop command to stop a VM that was running. - -**NOTE:** The command implementation is based on Openstack functionality. For further details, see http://developer.openstack.org/api-ref/compute/. - -+------------------------------+--------------------------------------------------------------------------------------------------------------------------------+ -| **Target URL** | /restconf/operations/appc-provider-lcm:stop | -+------------------------------+--------------------------------------------------------------------------------------------------------------------------------+ -| **Action** | Stop | -+------------------------------+--------------------------------------------------------------------------------------------------------------------------------+ -| **Action-identifiers** | vnf-id and vserver-id are required. | -+------------------------------+--------------------------------------------------------------------------------------------------------------------------------+ -| **Payload Parameters** | See table below | -+------------------------------+--------------------------------------------------------------------------------------------------------------------------------+ -| **Revision History** | Unchanged in this release | -+------------------------------+--------------------------------------------------------------------------------------------------------------------------------+ - -Payload Parameters - -+-----------------+-----------------------------------------------+-----------------+-----------------------------------------+ -| **Parameter** | **Description** | **Required?** | **Example** | -+=================+===============================================+=================+=========================================+ -| vm-id | The unique identifier (UUID) of | Yes | | -| | the resource. For backwards- | | "payload": | -| | compatibility, this can be the self- | | "{\\"vm-id\\": \\" | -| | link URL of the VM. | | \\", | -| | | | \\"identity-url\\": | -| | | | \\"\\", | -| | | | \\"tenant-id\\": \\"\\"}" | -+-----------------+-----------------------------------------------+-----------------+-----------------------------------------+ -| identity- url | The identity url used to access the | No | | -| | resource | | | -+-----------------+-----------------------------------------------+-----------------+-----------------------------------------+ -| tenant-id | The id of the provider tenant that owns | No | | -| | the resource | | | -+-----------------+-----------------------------------------------+-----------------+-----------------------------------------+ - - -StopApplication ---------------- - -Stops the VNF application gracefully (not lost traffic), if needed, prior to a Stop command. Supported using Chef cookbook or Ansible playbook only. - -A successful StopApplication request returns a success response. - -A failed StopApplication action returns a failure response code and the specific failure message in the response block. - -+------------------------------+--------------------------------------------------------------+ -| **Target URL** | /restconf/operations/appc-provider-lcm:stop-application | -+------------------------------+--------------------------------------------------------------+ -| **Action** | StopApplication | -+------------------------------+--------------------------------------------------------------+ -| **Action-Identifiers** | Vnf-id | -+------------------------------+--------------------------------------------------------------+ -| **Payload Parameters** | See table below | -+------------------------------+--------------------------------------------------------------+ -| **Revision History** | Unchanged in this release | -+------------------------------+--------------------------------------------------------------+ - -| - -+---------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------+-----------------------------------------------------------------+ -| **Payload Parameter** | **Description** | **Required?** | **Example** | -+=================================+====================================================================================================================================================================================+=====================+=================================================================+ -| configuration- parameters | A set of instance specific configuration parameters should be specified, as required by the Chef cookbook or Ansible playbook. | No | "payload": | -| | | | \\"configuration- parameters\\": {\\"\\"} | -+---------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------+-----------------------------------------------------------------+ - - -StopApplication Response -^^^^^^^^^^^^^^^^^^^^^^^^ - -The StopApplication response returns an indication of success or failure of the request. - -StopTraffic ------------ - -For StopTraffic LCM action, invoke the StopTraffic playbook. This is -limited to Ansible. - -A successful StopTraffic request returns a success response. - -A failed StopTraffic action returns a failure response code and the -specific failure message in the response block. - - -====================== ================================================== -**Target URL** /restconf/operations/appc-provider-lcm:StopTraffic -====================== ================================================== -**Action** Provisioning -**Action-Identifiers** vnf-id -**Payload Parameters** See table -**Revision History** New in Frankfurt -====================== ================================================== - -========================= ========================================================================================================= ============= ======================================================================== -**Payload Parameter** **Description** **Required?** **Example** -========================= ========================================================================================================= ============= ======================================================================== -request- parameters Not used. This request is limited to Ansible only. No "action": "StopTraffic", - - "action-identifiers": { - - "vnf-id": "rarf9901v" - - }, - - "payload": "{\"configuration-parameters\":{\"vnf_name\":\"rarf9901v\"}}" -configuration- parameters A set of instance specific configuration parameters should be specified, as required by Ansible playbook. No -========================= ========================================================================================================= ============= ======================================================================== - -StopTraffic Response\ **:** -~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Success: A successful StopTraffic returns a success status code 400. - -Failure: A failed StopTraffic returns a failure code 401 and the failure -message. - - -Sync ----- - -The Sync action updates the current configuration in the APPC store with the running configuration from the device. - -A successful Sync returns a success status. - -A failed Sync returns a failure response status and failure messages in the response payload block. - -This command can be applied to any VNF type. The only restriction is that the VNF has been onboarded in self-service mode (which requires that the VNF supports a request to return the running configuration). - -+------------------------------+---------------------------------------------------+ -| **Target URL** | /restconf/operations/appc-provider-lcm:sync | -+------------------------------+---------------------------------------------------+ -| **Action** | Sync | -+------------------------------+---------------------------------------------------+ -| **Action-identifiers** | Vnf-id | -+------------------------------+---------------------------------------------------+ -| **Payload Parameters** | See below | -+------------------------------+---------------------------------------------------+ -| **Revision History** | Unchanged in this release. | -+------------------------------+---------------------------------------------------+ - -+----------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------+----------------------------------+ -| **Parameter** | **Description** | **Required?** | **Example** | -+======================+===========================================================================================================================================================+=====================+==================================+ -| publish-config | \* If the publish\-config field is set to Y in the payload, then always write the running configuration to file | Yes | "publish-config": "" | -| | | | | -| | \* If the publish\-config field is set to N in the payload, then running configuration is not written to the file | | | -| | | | | -+----------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------+----------------------------------+ - - -Unlock ------- - -Run the Unlock command to release the lock on a VNF and allow other clients to perform LCM commands on that VNF. - -Unlock is a command intended for APPC and does not execute an actual VNF command. Instead, unlock will release the VNF from the exclusive access held by the specific request-id allowing other requests for the VNF to be accepted. - -The Unlock command will result in success if the VNF successfully unlocked or if it was already unlocked, otherwise commands will be rejected. - -The Unlock command will only return success if the VNF was locked with same request-id. - -The Unlock command returns only one final response with the status of the request processing. - -Note: APPC locks the target VNF during any command processing. If an Unlock action is then requested on that VNF with a different request-id, it will be rejected because the VNF is already locked for another process, even though no actual lock command was explicitly invoked. - -+------------------------------+-----------------------------------------------------+ -| **Target URL** | /restconf/operations/appc-provider-lcm:unlock | -+------------------------------+-----------------------------------------------------+ -| **Action** | Unlock | -+------------------------------+-----------------------------------------------------+ -| **Action-identifiers** | Vnf-id | -+------------------------------+-----------------------------------------------------+ -| **Payload Parameters** | see table below | -+------------------------------+-----------------------------------------------------+ -| **Revision History** | Unchanged in this release. | -+------------------------------+-----------------------------------------------------+ - -| - -+---------------------------------+-------------------------------------------------------------------------+---------------------+----------------------------------+ -| **Payload Parameter** | **Description** | **Required?** | **Example** | -+=================================+=========================================================================+=====================+==================================+ -| request-id | Request id from the previously submitted request | Yes | "request-id": "123456789" | -+---------------------------------+-------------------------------------------------------------------------+---------------------+----------------------------------+ - - -UpgradeBackout --------------- - -The UpgradeBackout LCM action does a backout after an UpgradeSoftware is completed (either successfully or unsuccessfully). - -This command is executed using an Ansible playbook or Chef cookbook. - -Request Structure: The request payload includes an upgrade identifier. - -+--------------------------+----------------------------------------------------------+ -| **Target URL** | /restconf/operations/appc-provider-lcm:upgrade-backout | -+--------------------------+----------------------------------------------------------+ -| **Action** | UpgradeBackout | -+--------------------------+----------------------------------------------------------+ -| **Action-identifiers** | vnf-id | -+--------------------------+----------------------------------------------------------+ -| **Payload Parameters** | existing-software-version, new-software-version | -+--------------------------+----------------------------------------------------------+ -| **Revision History** | New in Beijing | -+--------------------------+----------------------------------------------------------+ - -Request Payload Parameters: - -+-----------------------+-------------------------------------+---------------------+-----------------------------------------------------------------------------------------------+ -| **Parameter** | **Description** | **Required?** | **Example** | -+=======================+=====================================+=====================+===============================================================================================+ -| existing-software- | The existing software version | Yes | "payload": | -| version | prior to the upgrade | | "{\\"existing-software-version\\": \\"3.1\\", "{\\"new-software-version\\": \\"3.2\\"}” | -+-----------------------+-------------------------------------+---------------------+ | -| new-software- | The new software | Yes | | -| version | version after the | | | -| | upgrade | | | -+-----------------------+-------------------------------------+---------------------+-----------------------------------------------------------------------------------------------+ - -UpgradeBackout Response -^^^^^^^^^^^^^^^^^^^^^^^ - -**Success:** A successful backout returns a success status code 400. - -**Failure:** A failed backout returns a failure code 401 and the failure message from the Ansible or Chef server in the response payload block. - -UpgradeBackup -------------- - -The UpgradeBackup LCM action does a full backup of the VNF data prior to an upgrade. The backup is done on the Ansible or Chef server in a location that is specified in the playbook or cookbook. If there is an existing backup, it is overwritten by the new backup. - -This command is executed using an Ansible playbook or Chef cookbook. - -Request Structure: The payload does not have any parameters required. - -+--------------------------+---------------------------------------------------------+ -| **Target URL** | /restconf/operations/appc-provider-lcm:upgrade-backup | -+--------------------------+---------------------------------------------------------+ -| **Action** | UpgradeBackup | -+--------------------------+---------------------------------------------------------+ -| **Action-identifiers** | vnf-id | -+--------------------------+---------------------------------------------------------+ -| **Payload Parameters** | existing-software-version, new-software-version | -+--------------------------+---------------------------------------------------------+ -| **Revision History** | New in Beijing. | -+--------------------------+---------------------------------------------------------+ - -Request Payload Parameters: - -+-----------------------+-------------------------------------+---------------------+-----------------------------------------------------------------------------------------------+ -| **Parameter** | **Description** | **Required?** | **Example** | -+=======================+=====================================+=====================+===============================================================================================+ -| existing-software- | The existing software version | Yes | "payload": | -| version | prior to the upgrade | | "{\\"existing-software-version\\": \\"3.1\\", "{\\"new-software-version\\": \\"3.2\\"}” | -+-----------------------+-------------------------------------+---------------------+ | -| new-software- | The new software | Yes | | -| version | version after the | | | -+-----------------------+-------------------------------------+---------------------+-----------------------------------------------------------------------------------------------+ - -UpgradeBackup Response -^^^^^^^^^^^^^^^^^^^^^^ - -**Success:** A successful backup returns a success status code 400. - -**Failure:** A failed backup returns a failure code 401 and the failure message from the Ansible or Chef server in the response payload block. - -UpgradePostCheck ----------------- - -The UpgradePostCheck LCM action checks that the VNF upgrade has been successful completed and all processes are running properly. - -This command is executed using an Ansible playbook or Chef cookbook. - -Request Structure: - -+--------------------------+-------------------------------------------------------------+ -| **Target URL** | /restconf/operations/appc-provider-lcm:upgrade-post-check | -+--------------------------+-------------------------------------------------------------+ -| **Action** | UpgradePostCheck | -+--------------------------+-------------------------------------------------------------+ -| **Action-identifiers** | vnf-id | -+--------------------------+-------------------------------------------------------------+ -| **Payload Parameters** | existing-software-version, new-software-version | -+--------------------------+-------------------------------------------------------------+ -| **Revision History** | New in Beijing | -+--------------------------+-------------------------------------------------------------+ - -Request Payload Parameters: - -+-----------------------+-------------------------------------+---------------------+-----------------------------------------------------------------------------------------------+ -| **Parameter** | **Description** | **Required?** | **Example** | -+=======================+=====================================+=====================+===============================================================================================+ -| existing- software- | The existing software version | Yes | "payload": | -| version | prior to the upgrade | | "{\\"existing-software-version\\": \\"3.1\\", "{\\"new-software-version\\": \\"3.2\\"}” | -+-----------------------+-------------------------------------+---------------------+ | -| new-software- | The new software | Yes | | -| version | version after the | | | -+-----------------------+-------------------------------------+---------------------+-----------------------------------------------------------------------------------------------+ - -UpgradePostCheck Response -^^^^^^^^^^^^^^^^^^^^^^^^^ - -**Success:** If the UpgradePostCheck run successfully, it returns a success status code 400. The response payload contains the results of the check (Completed or Failed). - -Response Payload Parameters: - -+---------------+-----------------------------+-------------+------------------------------------------------------------------------------+ -| **Parameter** | **Description** |**Required?**| **Example** | -+===============+=============================+=============+==============================================================================+ -| Upgrade- | Returns the status | Yes | | -| Status | of the upgradw | | "payload": | -| | post-check. Indicates | | "{\\"upgrade-status\\": \\"Completed\\"}” | -| | Completed or Failed | | "payload": "{\\"upgrade-status\\": | -| | | | \\"Failed\\",\\"message\\": \\"Version 3.2 is not running properly\\" }” | -+---------------+-----------------------------+-------------+ | -| Message | If Not Available, | | | -| | message contains | | | -| | explanation. | | | -+---------------+-----------------------------+-------------+------------------------------------------------------------------------------+ - -**Failure:** If the UpgradePostCheck could not be run, it returns a failure code 401 and the failure message from the Ansible or Chef server in the response payload block. - -UpgradePreCheck ---------------- - -The UpgradePreCheck LCM action checks that the VNF has the correct software version needed for a software upgrade. This command can be executed on a running VNF (i.e. processing traffic). - -This command is executed using an Ansible playbook or Chef cookbook. - -Request Structure: - -+--------------------------+------------------------------------------------------------+ -| **Target URL** | /restconf/operations/appc-provider-lcm:upgrade-pre-check | -+--------------------------+------------------------------------------------------------+ -| **Action** | UpgradePreCheck | -+--------------------------+------------------------------------------------------------+ -| **Action-identifiers** | vnf-id | -+--------------------------+------------------------------------------------------------+ -| **Payload Parameters** | existing-software-version, new-software-version | -+--------------------------+------------------------------------------------------------+ -| **Revision History** | New in Beijing | -+--------------------------+------------------------------------------------------------+ - -Request Payload Parameters: - -+-----------------------+-------------------------------------+---------------------+-----------------------------------------------------------------------------------------------+ -| **Parameter** | **Description** | **Required?** | **Example** | -+=======================+=====================================+=====================+===============================================================================================+ -| existing-software- | The existing software version | Yes | "payload": | -| version | prior to the upgrade | | "{\\"existing-software-version\\": \\"3.1\\", "{\\"new-software-version\\": \\"3.2\\"}” | -+-----------------------+-------------------------------------+---------------------+ | -| new-software- | The new software | Yes | | -| version | version after the | | | -| | upgrade | | | -+-----------------------+-------------------------------------+---------------------+-----------------------------------------------------------------------------------------------+ - -UpgradePreCheck Response -^^^^^^^^^^^^^^^^^^^^^^^^ - -**Success:** If the UpgradePreCheck runs successfully, it returns a success status code 400. The response payload contains the results of the check (Available or Not Available for upgrade). - -Response Payload Parameters: - -+-----------------+---------------------------+---------------------+----------------------------------------------------------------------------------------------------------------------------------+ -| **Parameter** | **Description** | **Required?** | **Example** | -+=================+===========================+=====================+==================================================================================================================================+ -| upgrade-status | Returns the status | Yes | | -| | of the upgrade pre- | | "payload": | -| | check. Indicates | | "{\\"upgrade-status\\": \\"Available\\"}” | -| | Available or Not | | | -| | Available | | "payload": | -| | | | "{\\"upgrade-status\\": \\"Not Available\\",\\"message\\": \\"Current software version 2.9 cannot be upgraded to 3.1\\" }” | -+-----------------+---------------------------+---------------------+ | -| message | If Not Available, | | | -| | message contains | | | -| | explanation. | | | -+-----------------+---------------------------+---------------------+----------------------------------------------------------------------------------------------------------------------------------+ - -**Failure:** If an UpgradePreCheck fails to run, it returns a failure code 401 and the failure message from the Ansible or Chef server in the response payload block. - -UpgradeSoftware ---------------- - -The UpgradeSoftware LCM action upgrades the target VNF to a new version. It is expected that the VNF is in a quiesced status (not processing traffic). - -This command is executed using an Ansible playbook or Chef cookbook. - -Request Structure: The request payload includes the new-software-version. - -+--------------------------+-----------------------------------------------------------+ -| **Target URL** | /restconf/operations/appc-provider-lcm:upgrade-software | -+--------------------------+-----------------------------------------------------------+ -| **Action** | UpgradeSoftware | -+--------------------------+-----------------------------------------------------------+ -| **Action-identifiers** | vnf-id | -+--------------------------+-----------------------------------------------------------+ -| **Payload Parameters** | existing-software-version, new-software-version | -+--------------------------+-----------------------------------------------------------+ -| **Revision History** | New in Beijing | -+--------------------------+-----------------------------------------------------------+ - - Request Payload Parameters: - -+-----------------------+-------------------------------------+---------------------+-----------------------------------------------------------------------------------------------+ -| **Parameter** | **Description** | **Required?** | **Example** | -+=======================+=====================================+=====================+===============================================================================================+ -| existing- software- | The existing software version | Yes | "payload": | -| version | prior to the upgrade | | "{\\"existing-software-version\\": \\"3.1\\", "{\\"new-software-version\\": \\"3.2\\"}” | -+-----------------------+-------------------------------------+---------------------+ | -| new-software | The new software | Yes | | -| version | version after the | | | -| | upgrade | | | -+-----------------------+-------------------------------------+---------------------+-----------------------------------------------------------------------------------------------+ - -UpgradeSoftware Response -^^^^^^^^^^^^^^^^^^^^^^^^ - -**Success:** A successful upgrade returns a success status code 400. - -If an UpgradeSoftware command is executed and the software has been previously upgraded to this version, it should return a success status. - -**Failure:** A failed upgrade returns a failure code 401 and the failure message from the Ansible or Chef server in the response payload block. A failure does not assume that the software upgrade has been rolled back. - -Notes regarding the Upgrade commands -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Ansible playbooks / Chef cookbooks: - -- All Ansible playbooks/cookbooks for the Upgrade commands will be - stored in the same directory on the server. The directory name will - be of the format: - - {existing-software-version_new-software-version}. - - The path to the directory is the same for all upgrades (for example: vnf-type/softwareupgrade). - -- The playbooks for upgrades should use a standard naming convention - (for example: SoftwareUpgrade_{existing-software-version_new-software-version}). - -APPC template: The APPC templates for the Upgrade commands can be common across upgrades for the vnf-type if the path and filenames are standardized. - -- The template will contain the directory path/playbook name which - would be parameterized. - - {vnf-type}/UpgradeSoftware/${existing_software_version}_${new-software-version}/ - SoftwareUpgrade_{existing-software-version_new-software-version}. - - diff --git a/docs/APPC Logging Guide/APPC Logging Guide.rst b/docs/APPC Logging Guide/APPC Logging Guide.rst deleted file mode 100644 index 274567c6a..000000000 --- a/docs/APPC Logging Guide/APPC Logging Guide.rst +++ /dev/null @@ -1,334 +0,0 @@ -.. ============LICENSE_START========================================== -.. =================================================================== -.. Copyright © 2017 AT&T Intellectual Property. All rights reserved. -.. =================================================================== -.. Licensed under the Creative Commons License, Attribution 4.0 Intl. (the "License"); -.. you may not use this documentation except in compliance with the License. -.. You may obtain a copy of the License at -.. -.. https://creativecommons.org/licenses/by/4.0/ -.. -.. Unless required by applicable law or agreed to in writing, software -.. distributed under the License is distributed on an "AS IS" BASIS, -.. WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. -.. See the License for the specific language governing permissions and -.. limitations under the License. -.. ============LICENSE_END============================================ -.. ECOMP is a trademark and service mark of AT&T Intellectual Property. - -APPC Logging Guide -================== - -The APPC modules manage logging functionality according to the logging -configuration file ``org.ops4j.pax.logging.cfg``. APPC configuration defines -the location of the logging configuration file. Each APPC module -configured to generate logs reads the configuration file periodically -and generates logs according to the current logging level. - -Logging Architecture ---------------------- - -The following diagram illustrates the APPC logging architecture. - -|image0| - -Log Types ---------- - -APPC generates several types of logs to capture information needed to -operate, troubleshoot, and report on performance: - -- **Audit Log**: The Audit Log provides a summary view of the - processing of a request – a transaction – within an application. It - captures activity requests received by APPC and includes such - information as the time the activity initiated, when it finishes, and - the API invoked at the component. - -- **Metric Log**: The Metrics Log provides a more detailed view into - the processing of a transaction within APP-C. It captures the - beginning and ending of activities necessary to complete the - transaction within APPC modules, for example, the Dispatcher module, - and other ONAP components such as A&AI. - -- **Error Log**: The Error Log captures INFO, WARN, ERROR, and FATAL - conditions sensed (“exception handled”) by the APPC software - components. - -- **Debug Log**: The optional Debug Log captures data that may be required to debug and correct abnormal conditions of the application. - - -The APPC modules manage logging functionality according to the logging -configuration file ``org.ops4j.pax.logging.cfg``. APPC configuration defines -the location of the logging configuration file. Each APPC module -configured to generate logs reads the configuration file periodically -and generates logs according to the current logging level. - -Logging Levels -~~~~~~~~~~~~~~ - -+-------------+----------------+---------------+-------------+-------------+------------+ -| **Level** | **Log type** | -+=============+================+===============+=============+=============+============+ -| | | **Errors** | -+-------------+----------------+---------------+-------------+-------------+------------+ -| | **Audit** | **Metrics** | **FATAL** | **ERROR** | **WARN** | -+-------------+----------------+---------------+-------------+-------------+------------+ -| OFF | No | No | No | No | No | -+-------------+----------------+---------------+-------------+-------------+------------+ -| FATAL | Yes | Yes | Yes | No | No | -+-------------+----------------+---------------+-------------+-------------+------------+ -| ERROR | Yes | Yes | Yes | Yes | No | -+-------------+----------------+---------------+-------------+-------------+------------+ -| WARN | Yes | Yes | Yes | Yes | Yes | -+-------------+----------------+---------------+-------------+-------------+------------+ - -Response Codes -~~~~~~~~~~~~~~ - -+----------------------------+--------------------------------+ -| **Response code ranges** | **Error type** | -+============================+================================+ -| 100-199 | Permission errors | -+----------------------------+--------------------------------+ -| 200-299 | Availability errors/Timeouts | -+----------------------------+--------------------------------+ -| 300-399 | Data errors | -+----------------------------+--------------------------------+ -| 400-499 | Schema errors | -+----------------------------+--------------------------------+ -| 500-599 | Business process errors | -+----------------------------+--------------------------------+ -| 900-999 | Unknown errors | -+----------------------------+--------------------------------+ - -Logging Output ---------------- - -APPC generates logging output according to Event and Error Logging Framework(EELF)requirements in the -following format: - -Error Log -~~~~~~~~~~ - -+-------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| **Field** | **Description** | -+=========================+=================================================================================================================================================================================================================================================+ -| Timestamp | Date-time when error occurs in UTC. | -+-------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| RequestID | Universally unique transaction requestID (UUID). | -+-------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| ThreadId | Blank | -| | | -| | This traces processing of a request over a number of threads of a single ONAP component. | -+-------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| ServiceName | Externally advertised API invoked by clients of this component, for example, "Audit", "HealthCheck". | -+-------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| PartnerName | Client or user invoking the API. | -+-------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| TargetEntity | ONAP component/subcomponent or non-ONAP entity invoked for this suboperation’s activities, for example, A&AI, VF, VM, MySql. | -+-------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| TargetServiceName | Known name of External API/operation activities invoked on TargetEntity (ONAP component/subcomponent or non-ONAP entity), for example, VM UUID, VF UUID. | -+-------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| ErrorCategory | WARN or ERROR | -+-------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| ErrorCode | Code representing the error condition according to the error categories. | -+-------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| ErrorDescription | Human readable description of the error - Error name, for example: "CONFIGURATION\_STARTED". | -+-------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| detailMessage | This field may contain any additional information useful in describing the error condition, for example: | -| | | -| | ``Application Controller (APP-C) initialization started at {0}|\`` | -| | ``No resolution is required, this is an informational message|\`` | -| | ``The APP-C component configuration has been started because the component is being initialized or loaded for the first time, or a new instance of the component is being created. This message indicates that the component is starting.`` | -+-------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - -Debug Log -~~~~~~~~~ - -+-----------------+------------------------------------------------------------+ -| **Field** | **Description** | -+=================+============================================================+ -| Timestamp | Date-time of the log record. | -+-----------------+------------------------------------------------------------+ -| RequestID | Universally unique transaction requestID (UUID). | -+-----------------+------------------------------------------------------------+ -| DebugInfo | Debug Information | -+-----------------+------------------------------------------------------------+ -| End of Record | Designates the logical end of a multi-line debug record. | -+-----------------+------------------------------------------------------------+ - -Audit Log -~~~~~~~~~ - -+--------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| **Field** | **Description** | -+======================================+===========================================================================================================================================================================================================+ -| BeginTimestamp | Date-time of the start of a request activity. | -+--------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| EndTimestamp | Date-time of the end of a request activity. | -+--------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| RequestID | Universally unique transaction request ID (UUID). | -+--------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| serviceInstanceID | Uniquely identifies a service instance, for example, “service graph”. The primary key, for example, in A&AI, to reference or manage the service instance as a unit. | -+--------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| threadId | Empty | -+--------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| physical/virtual server name   | Empty (the value added by the log files collecting agent). | -+--------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| serviceName  | Externally advertised API invoked by clients of this component, for example, "Audit", "HealthCheck". | -+--------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| PartnerName | Client or user invoking the API.   | -+--------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| StatusCode | High-level success or failure of the request (COMPLETE or ERROR). | -+--------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| ResponseCode | Application specific response code - LCM API error codes categorized according to the logging categories. | -+--------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| ResponseDescription | Human readable description of the application specific response code, for example, "INVALID INPUT PARAMETER - ${detailedErrorMsg}". | -+--------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| instanceUUID | Universally unique identifier to differentiate between multiple instances of the same (named), log writing component - the specific APPC instance UUID. | -+--------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| Category log level | Enum: “INFO” \| “WARN” \|”DEBUG” \| “ERROR” \| “FATAL”. Current log level for the entire APP-C. | -+--------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| Severity | Blank | -+--------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| Server IP address  | Blank | -+--------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| ElapsedTime | Elapsed time to complete processing of an API or request at the granularity available to the component system. This value should be the difference between BeginTimestamp and EndTimestamp fields.  | -+--------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| Server | VM FQDN if virtualized, otherwise the host name of the logging component.  | -+--------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| ClientIPaddress | Requesting remote client application’s IP address if known, otherwise empty. | -+--------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - -Metrics Log -~~~~~~~~~~~ - -+-----------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| **Field** | **Description** | -+===============================================+==================================================================================================================================================================================================================+ -| BeginTimestamp | Date-time when a suboperation activity is begun in UTC | -+-----------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| EndTimestamp | Date-time when a supoperation activity is completed in UTC | -+-----------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| RequestID | Universally unique transaction request ID (UUID) | -+-----------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| serviceInstanceID       | VMUUID, VFUUID | -+-----------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| threadId | Optional | -+-----------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| physical/virtual server name | Empty if its value can be added by the log files collecting agent. | -+-----------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| serviceName | For example: "Audit", "HealthCheck" etc | -+-----------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| PartnerName Client or user invoking the API | | -+-----------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| TargetEntity  | APPC internal subcomponent, for example, MD-SAL, or external component, for example, A&AI, SSH, Netconf, invoked for this suboperation. | -+-----------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| TargetServiceName   | Operation activities invoked on TargetEntity e.g. A&AI GET generic- vnf | -+-----------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| StatusCode | High level success or failure of the suboperation activities (COMPLETE or ERROR) | -+-----------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| ResponseCode | Specific response code returned by the suboperation activities. | -+-----------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| ResponseDescription | Human readable description of the response code. | -+-----------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| instanceUUID  | APPC instance ID. | -+-----------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| Category log level | Enumerated values: “INFO” \| “WARN” \|”DEBUG” \| “ERROR” \| “FATAL”. | -+-----------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| Severity | Empty | -+-----------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| Server IP address | The logging component host server’s IP address. | -+-----------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| ElapsedTime | Elapsed time to complete processing of the sub operation activities at the granularity available to the component system.  This value should be the difference between EndTimestamp and BeginTimestamp fields. | -+-----------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| Server | VM FQDN if virtualized, otherwise the host name of the logging component. | -+-----------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| ClientIP | Requesting remote client application’s IP address. | -+-----------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| class name | Optional. The name of the class that has caused the log record creation. For OO programing languages that support this concept. | -+-----------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| Unused  | | -+-----------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| ProcessKey | Optional | -+-----------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| TargetVirtualEntity | Empty | -+-----------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| CustomField1 | Empty (specific attributes exposed by developers) | -+-----------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| CustomField2 | Empty | -+-----------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| CustomField3 | Empty | -+-----------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| CustomField4 | Empty | -+-----------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| detailMessage | Empty | -+-----------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - -Log File Locations ------------------- - -The logging configuration file, ``org.ops4j.pax.logging.cfg`` are located in -appc Git repository: - -``/appc/appc-common/src/main/resources/org/onap/appc/org.ops4j.pax.logging.cfg`` - - -The logs are stored at the location defined by the appropriate appender: - -``log4j.appender.error.File=${karaf.data}/log/APPC/appc-error.log`` - -``log4j.appender.debug.file=${karaf.data}/log/APPC/appc-debug.log`` - -``log4j.appender.metric.File=${karaf.data}/log/APPC/appc-metric.log`` - -``log4j.appender.audit.File=${karaf.data}/log/APPC/appc-audit.log`` - - -Enabling APPC Logging ----------------------- - -APPC uses Event and Error Logging Framework (EELF) for application logs. -To enable EELF logging: - -1. Replace the default configuration file located at - ``/opt/opendaylight/current/etc/org.ops4j.pax.logging.cfg`` - - with the configuration file that is checked into git: - - ``/appc/appc-common/src/main/resources/org/onap/appc/org.ops4j.pax.logging.cfg`` - -2. Stop and restart ODL controller for the configuration changes to take - effect. - -3. Verify logging changes at the following log paths: - - - ``/opt/opendaylight/current/data/log/eelf/karaf.log`` - This log contains the regular karaf.log output reformatted to use - the EELF MDC properties and the pattern that is configured in the - ``org.ops4j.pax.logging.cfg`` file. - - ``/opt/opendaylight/current/data/log/APPC/`` - This directory contains the audit, metric, error, and debug logs that are configured in the ``org.ops4j.pax.logging.cfg`` file. - - -**Note:** - ``/opt/opendaylight/current/data/log/APPC/controller`` contains the logs generated from the package ``org.openecomp.\*`` (all APPC logs) - -- Error.log: alarms –ERROR level logs and above - -- Info.log: INFO level logs only - -- Debug.log: debugging – DEBUG level and above - -- Audit – AUDIT level and above - -Log Rotation ------------- - -Log rotation is performed after every 100 MB size limit is reached. The -log rotation interval is defined as part of the EELF framework. - -.. |image0| image:: APPCLoggingArchitecturediagram.png - :width: 6.49097in - :height: 3.46181in - diff --git a/docs/APPC Logging Guide/APPCLoggingArchitecturediagram.png b/docs/APPC Logging Guide/APPCLoggingArchitecturediagram.png deleted file mode 100644 index 4ed155c05..000000000 Binary files a/docs/APPC Logging Guide/APPCLoggingArchitecturediagram.png and /dev/null differ diff --git a/docs/APPC OAM API Guide/APPC OAM API Guide.rst b/docs/APPC OAM API Guide/APPC OAM API Guide.rst deleted file mode 100644 index 4d4d93a52..000000000 --- a/docs/APPC OAM API Guide/APPC OAM API Guide.rst +++ /dev/null @@ -1,548 +0,0 @@ -.. ============LICENSE_START========================================== -.. =================================================================== -.. Copyright © 2017 AT&T Intellectual Property. All rights reserved. -.. =================================================================== -.. Licensed under the Creative Commons License, Attribution 4.0 Intl. (the "License"); -.. you may not use this documentation except in compliance with the License. -.. You may obtain a copy of the License at -.. -.. https://creativecommons.org/licenses/by/4.0/ -.. -.. Unless required by applicable law or agreed to in writing, software -.. distributed under the License is distributed on an "AS IS" BASIS, -.. WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. -.. See the License for the specific language governing permissions and -.. limitations under the License. -.. ============LICENSE_END============================================ -.. ECOMP is a trademark and service mark of AT&T Intellectual Property. - -APPC OAM API Guide -================== - -This guide describes the APPC OAM API that allows the user to manage and control the APPC application/component itself. - -APPC OAM Overview ------------------ - -APPC **OAM** API commands affect the state of the APPC application instance itself; whereas the APPC **LCM** API commands are issued via APPC and affect the state of VM/VNF/VNFCs. - -The APPC OAM API currently provides the following commands: - -+--------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| **APPC OAM API** | **Description** | -+====================+==============================================================================================================================================================+ -| maintenance-mode | Puts the APPC instance into maintenance mode. When APPC is in Maintenance Mode, | -| | | -| | - APPC will stop accepting new requests | -| | | -| | - The action will be considered complete once all existing requests have completed | -+--------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| get-appc-state | Returns the current state of the running APPC instance | -+--------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| get-metrics | Gets list of registered Metrics in APP-C | -+--------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| stop | Force stop an APPC instance. In this mode, all APPC bundles will be stopped via an OSGI API | -+--------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| restart | Restarts an APPC instance, picking up any configuration changes. This command invokes the stop command followed by the start command. | -+--------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| start | Starts the APPC instance; enables appc-provider-lcm so that it can begin to accept LCM request. This includes starting any APPC bundles which are stopped. | -+--------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------+ - -The APPC database data is not affected by any of the OAM operations. The existing APPC configurations are not affected unless a Stop or Restart command is issues (just putting the APPC into maintenance mode and then starting it again is not sufficient). Notifications are sent out for state transitions. Refer to table below for details on state transitions supported. - -Detailed Description --------------------- - -All APIs are implemented via RESTCONF and can be access via the Application Controller dashboard. - -To access the dashboard, go to: ``https://:8282/apidoc/explorer/index.html`` - -You should see something similar to below. - - .. image:: media/AppcAPIdocdiagram.png - -The current set of OAM APIs currently available are: - -- maintenance-mode -- get-appc-state -- get-metrics -- stop -- restart -- start - -These commands operate on the APPC instance. Some usage notes below - -- After a Start or Restart, the APPC should be fully operational, meaning that all APPC bundles have been started, MYSQL is running, and the APPC is accepting new requests - -- When issuing the API which puts the APPC into maintenance mode, wait for all existing operations to complete - - - If the existing operations still have not completed after a maximum timeout of 60 minutes, the API will abort and be considered as having failed - -- Issuing a Stop does not wait for existing operations to complete - - - If you want to wait for all existing operations to complete and then stop the APPC, then first issue the API to put the APPC into maintenance mode and \ *then* issue a Stop API - - - There is a flag on the stop operation to make it "brutal" in order to skip waiting for requests to complete - -- If you change the configuration parameters before performing a restart, it should pick up the new configuration parameters - -- A healthy APPC instance is one which: - - - Can talk to DMaaP - - Can talk to A&AI - - Has all Karaf bundles from an APPC installation running - - Has MYSQL running - -OAM-API State Transitions --------------------------- - -The table below documents the current state transition behaves. This is currently hard coded. - -+--------------------------+-------------------+----------------------------+----------------+-----------------+----------------------------------+-----------------------+------------------+-------------+ -| **OAM API Command** | **APPC Status** | -+==========================+===================+============================+================+=================+==================================+=======================+==================+=============+ -| | **Started** | **In Maintenance Mode** | **Stopped** | **Starting** | **Entering Maintenance Mode** | **Force Stopping** | **Restarting** | **Error** | -+--------------------------+-------------------+----------------------------+----------------+-----------------+----------------------------------+-----------------------+------------------+-------------+ -| Start | Reject | Accept | Accept | Reject | Reject | Reject | Reject | Accept | -+--------------------------+-------------------+----------------------------+----------------+-----------------+----------------------------------+-----------------------+------------------+-------------+ -| Enter Maintenance Mode | Accept | Reject | Reject | Reject | Reject | Reject | Reject | Reject | -+--------------------------+-------------------+----------------------------+----------------+-----------------+----------------------------------+-----------------------+------------------+-------------+ -| Force Stop | Accept | Accept | Reject | Accept | Accept | Reject | Reject | Accept | -+--------------------------+-------------------+----------------------------+----------------+-----------------+----------------------------------+-----------------------+------------------+-------------+ -| Restart | Accept | Accept | Accept | Accept | Accept | Reject | Reject | Accept | -+--------------------------+-------------------+----------------------------+----------------+-----------------+----------------------------------+-----------------------+------------------+-------------+ - -OAM Commands ------------- - -This section descripted the OAM API commands that are available for the Amsterdam release. - -Maintenance Mode API -~~~~~~~~~~~~~~~~~~~~ - -**Functional Description:** - -- Puts an APP-C instance into the Maintenance Mode state -- Waits for all currently executing or queued requests to complete -- Can only be issued from the Started state - -  - -**Request (Input) Example:** - -**POST** ``https://10.147.104.163:8443/restconf/operations/appc-oam:maintenance-mode`` - - :: - - { - "input": { - "common-header": { - "flags": { - "request-timeout": "0" - }, - "request-id": " ecompController ", - "originator-id": "demo-oam-maintenanceMode-id#1" - } - } - } - -   - -**Response (Output) Example:** - - **Maintenance-mode Response – Success Case** - - :: - -   { - "output": { - "status": { - "code": 100, - "message": "ACCEPTED - request accepted" - }, - "common-header": { - "request-id": "demo-oam-maintenanceMode-id#1", - "originator-id": "ecompController" - } - } - } - - - **Maintenance-mode Response – Rejection Case** - - :: - - { - "output": { - "status": { - "code": 300, - "message": "REJECTED - Invalid State Transition" - }, - "common-header": { - "request-id": "demo-oam-maintenanceMode-id#1", - "originator-id": "ecompController" - } - } - } - - -**Audit Log Examples- Success Case** - - :: - - 2017-06-02T13:58:55Z\|2017-06-02T13:58:55Z\|demo-oam-maintenance-mode-id#1\|\|qtp1068080075-58 - - - /restconf/operations/appc-oam:maintenance-mode\|appc\|maintenance\_mode\|ecompController\|COMPLETE\|100\|ACCEPTED - - request accepted\|\|INFO - \|\|127.0.0.1\|9\|localhost\|\|org.onap.appc.oam.AppcOam\|\|\|\|\|\|\|APPC0154W - Application APPC is entering maintenance mode... - - 2017-06-02T13:58:55Z\|2017-06-02T13:59:05Z\|demo-oam-maintenance-mode-id#1\|\|org.onap.appc.oam-bundle - scheduledExecutor\|appc\|maintenance\_mode\|ecompController\|COMPLETE\|400\|SUCCESS - - request has been processed successfully\|\|INFO - \|\|127.0.0.1\|10033\|localhost\|\|\|\|\|\|\|\|\|APPC0155W - Application APPC is in maintenance mode - -Get APPC State API -~~~~~~~~~~~~~~~~~~ - -**Functional Description:** - -- Retrieves the current state of the APP-C instance.  - - - If none of the other APPC State APIs have been used yet (i.e.; ``appc-oam:start``, ``appc-oam:maintenance-mode``, ``appc-oam:stop``, ``appc-oam:restart``), this command will read all the APPC-LCM bundles states and pick up the lowest bundle state as its response. - -- The APPC States versus the OSGI Bundle state mapping is defined as - follows: - -+---------------------------+-------------------------+ -| **Appc State** | **OSGi Bundle State** | -+===========================+=========================+ -| EnteringMaintenanceMode | ACTIVE | -+---------------------------+-------------------------+ -| Error | | -+---------------------------+-------------------------+ -| Instantiated | INSTALLED | -+---------------------------+-------------------------+ -| MaintenanceMode | ACTIVE | -+---------------------------+-------------------------+ -| NotInstantiated | UNINSTALLED | -+---------------------------+-------------------------+ -| Restarting | | -+---------------------------+-------------------------+ -| Started | ACTIVE | -+---------------------------+-------------------------+ -| Starting | STARTING | -+---------------------------+-------------------------+ -| Stopped | RESOLVED | -+---------------------------+-------------------------+ -| Stopping | STOPPING | -+---------------------------+-------------------------+ -| Unknown | | -+---------------------------+-------------------------+ - -**Request (Input) example:** - -**POST** ``https://10.147.104.163:8443/restconf/operations/appc-oam:get-appc-state`` - -**Response (Output) example:** - - **Response: Get-Appc-Status – when APPC in Running state** - - :: - - { - "output": { - "state": "Started" - } - } - - **Response: Get-Appc-Status – when APPC in Maintenance Mode state** - - :: - - { - "output": { - "state": "MaintenanceMode" - } - } - - **Response: Get-Appc-Status – when APPC in Entering-Maintenance-Mode state** - - :: - - { - "output": { - "state": "EnteringMaintenanceMode" - } - } - - **Response: Get-Appc-Status – when APPC in Error state** - - :: - - { - "output": { - "state": "Error" - } - - -Get Metrics API -~~~~~~~~~~~~~~~ - -**Functional Description:** - -- This operation gets list of registered Metrics in APPC. -- Metrics service must be enabled. - -**Request (Input) example:** - -**POST** ``https://10.147.104.163:8443/restconf/operations/appc-oam:get-metrics`` - -**Response (Output) example:** - - **Response: get-metrics-Status – when APPC Metrics service is not enabled** - - :: - - { - "errors": { - "error": [ - { - "error-type": "application", - "error-tag": "operation-failed", - "error-message": "Metric Service not enabled", - "error-info": "error" - } - ] - } - } - - -Stop API -~~~~~~~~ - -**Functional Description:** - -- Force stops the APPC bundles that accept LCM requests -- Does not wait for any currently executing or queued requests to complete -- Can be issued from the Started, Maintenance Mode, Starting or Entering Maintenance Mode states, - -**Request (Input) example:** - -**POST** ``https://10.147.104.163:8443/restconf/operations/appc-oam:stop`` - - :: - - { - "input": { - "common-header": { - "flags": { - "request-timeout": "0" - }, - "request-id": "ecompController",, - "originator-id": " demo-oam-stop-id#1" - } - } - } - -**Response (Output) example:** - - **Stop Response – Success Case**  Expand source - - :: - - { - "output": { - "status": { - "code": 100, - "message": "ACCEPTED - request accepted" - }, - "common-header": { - "request-id": "demo-oam-stop-id#1", - "originator-id": "ecompController" - } - } - } - -Restart API -~~~~~~~~~~~ - -**Functional Description:** - -- Restarts an APP-C instance -- Does not wait for any currently executing or queued requests to complete -- Can be issued from any state -- Restart command will - - - Tell dispatcher to start to reject new APPC LCM operation requests - - Immediately kill all currently running APPC LCM operations - - Stops all APPC bundles - - Stop MYSQL - - Start MYSQL - - Start all APPC Bundles - - Tell dispatcher to allow APPC to start accepting operations - - Return success - -- APPC DB data should not be affected -- Any configuration parameters which were changed prior to the restart have been picked up - -**Request (Input) example:** - -**POST** ``https://10.147.104.163:8443/restconf/operations/appc-oam:restart`` - - :: - - { - "input": { - "common-header" : { - "originator-id" : "ecompController", - "request-id" : "demo-oam-restart-id#1" - } - } - } - -**Response (Output) example:** - - **Restart Response – Success Case** - - :: - - { - "output": { - "status": { - "code": 100, - "message": "ACCEPTED - request accepted" - }, - "common-header": { - "request-id": "demo-oam-restart-id#1", - "originator-id": "ecompController" - } - } - } - - **Restart Response – Rejection case**  Expand source - - :: - - { - "output": { - "status": { - "code": 300, - "message": "REJECTED - Restart API is not allowed when APPC is in the Restarting state." - }, - "common-header": { - "request-id": "demo-oam-restart-id#1", - "originator-id": "ecompController" - } - } - } - -**Audit Log Examples - Success Case** - - :: - - C2017-06-23T16:11:02Z\|2017-06-23T16:11:02Z\|demo-oam-restart-id#1\|\|qtp1752316482-134 - - - /restconf/operations/appc-oam:restart\|appc\|restart\|ecompController\|COMPLETE\|100\|ACCEPTED - - request accepted\|\|INFO - \|\|127.0.0.1\|13\|localhost\|\|org.onap.appc.oam.AppcOam\|\|\|\|\|\|\|APPC0162W - Application APPC is Restarting - - 2017-06-23T16:11:02Z\|2017-06-23T16:11:51Z\|demo-oam-restart-id#1\|\|org.onap.appc.oam-bundle - scheduledExecutor\|appc\|restart\|ecompController\|COMPLETE\|400\|SUCCESS - - request has been processed successfully\|\|INFO - \|\|127.0.0.1\|49198\|localhost\|\|org.onap.appc.oam.AppcOam\|\|\|\|\|\|\|APPC0157I - Application APPC is Started - - - -Start API -~~~~~~~~~ - -**Functional Description:** - -- Starts an APP-C instance -- Can only be issued from the Stopped or Maintenance Mode states   - -**Request (Input) example:** - -**POST** ``https://10.147.104.163:8443/restconf/operations/appc-oam:start`` -   - :: - - { - "input": { - "common-header": { - "flags": { - "request-timeout": "0" - }, - "request-id": "ecompController", - "originator-id": "demo-oam-start-id#1" - } - } - } - -   -**Response (Output) example:** - - **Response: appc-oam:start – Success case** - - :: - - { - "output": { - "status": { - "code": 100, - "message": "ACCEPTED - request accepted" - }, - "common-header": { - "request-id": "demo-oam-start-id#1", - "originator-id": "ecompController" - } - } - } - - **Response: appc-oam-status – Rejection case** - - :: - - { - "output": { - "status": { - "code": 300, - "message": "REJECTED - Invalid State Transition" - }, - "common-header": { - "request-id": "demo-oam-start-id#1", - "originator-id": "ecompController" - } - } - } - -**Audit Log Examples** - - **Audit Log - Rejection** - - :: - - 2017-06-02T13:58:39Z\|2017-06-02T13:58:39Z\|\|\|qtp1068080075-57 - - /restconf/operations/appc-oam:start\|\|\|\|ERROR\|300\|REJECTED - - Invalid State Transition\|\|INFO - \|\|\|15\|\|\|org.onap.appc.oam.AppcOam\|\|\|\|\|\|\|APPC0156I - Application APPC is starting... - - **Audit Log - Success case** - - :: - - 2017-06-02T13:59:16Z\|2017-06-02T13:59:16Z\|demo-oam-start-id#1\|\|qtp1068080075-58- - /restconf/operations/appc-oam:start\|appc\|start\|ecompController\|COMPLETE\|100\|ACCEPTED - - request accepted\|\|INFO - \|\|127.0.0.1\|2\|localhost\|\|org.onap.appc.oam.AppcOam\|\|\|\|\|\|\|APPC0156I - Application APPC is starting... - 2017-06-02T13:59:16Z\|2017-06-02T13:59:17Z\|demo-oam-start-id#1\|\|org.onap.appc.oam-bundle - scheduledExecutor\|appc\|start\|ecompController\|COMPLETE\|400\|SUCCESS - - request has been processed successfully\|\|INFO - \|\|127.0.0.1\|1007\|localhost\|\|\|\|\|\|\|\|\|APPC0157I - Application APPC is started diff --git a/docs/APPC OAM API Guide/media/AppcAPIdocdiagram.png b/docs/APPC OAM API Guide/media/AppcAPIdocdiagram.png deleted file mode 100644 index f8d56abf9..000000000 Binary files a/docs/APPC OAM API Guide/media/AppcAPIdocdiagram.png and /dev/null differ diff --git a/docs/APPC User Guide/APPC User Guide.rst b/docs/APPC User Guide/APPC User Guide.rst deleted file mode 100644 index 82bbaa921..000000000 --- a/docs/APPC User Guide/APPC User Guide.rst +++ /dev/null @@ -1,1325 +0,0 @@ -.. ============LICENSE_START========================================== -.. =================================================================== -.. Copyright © 2017 AT&T Intellectual Property. All rights reserved. -.. =================================================================== -.. Licensed under the Creative Commons License, Attribution 4.0 Intl. (the "License"); -.. you may not use this documentation except in compliance with the License. -.. You may obtain a copy of the License at -.. -.. https://creativecommons.org/licenses/by/4.0/ -.. -.. Unless required by applicable law or agreed to in writing, software -.. distributed under the License is distributed on an "AS IS" BASIS, -.. WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. -.. See the License for the specific language governing permissions and -.. limitations under the License. -.. ============LICENSE_END============================================ -.. ECOMP is a trademark and service mark of AT&T Intellectual Property. - -=============== -APPC User Guide -=============== - -APPC Overview and Architecture -============================== -The Application Controller (APPC) is one of the components of the ONAP -platform. It is responsible for handling the Life Cycle Management (LCM) -of Virtual Network Functions (VNFs). - -This document provides an overview of the APPC components that enable -the LCM operations. - -Implementation --------------- -The APPC infrastructure is implemented on virtual machines in an -OpenStack cloud in the Amsterdam release. APPC is created on top of the OpenDaylight (ODL) -platform - -The following diagram represents a non-redundant APP-C deployment. - -|image0| - -Features --------- -The APPC HTTP API supports Life Cycle Management (LCM) commands, -allowing users to manage virtual applications and their components via -other ONAP components. Refer to Architecture section for further -details. - -Interface ---------- -The Application Controller Dashboard interacts with the controller -using REST APIs and performs actions on VNF/VNFC/VMs, such as snapshot, -lock, sync, and health-check. - -Dashboard -~~~~~~~~~ - -To open the Application Controller dashboard, go to: - -|image1| - -Navigate to the available LCM commands by clicking on - **appc-provider-lcm**: - -|image2| - -Click on the URI of the desired action to open a frame with information -about the action and an option to try it out. For example, to send the -action, add the request body as the input parameter value, and click -**Try it out!** - -The following figure shows an example body of a LCM restart request: - -|image3| - -If the request is accepted, you should see the following response: - -|image4| - -APPC Architecture ------------------ - -This section discusses the APPC internal components in detail. - -**APPC High Level Architecture** - -|image5| - -Northbound REST Layer -~~~~~~~~~~~~~~~~~~~~~ - -This layer is responsible for interfacing with APPC clients, such as SO -or SDC and others, exposing YANG-based API via REST HTTP and/or DMaaP -messaging (see the Interfaces Summary section for details). In addition, -it exposes APPC OAM (Operation Administration Management) APIs, enabling -ONAP Operations Manager (OOM) or TechOps portal to perform APPC -lifecycle operations - -APPC Provider -~~~~~~~~~~~~~ - -The APPC Provider module exposes the endpoints for each action -supported by APPC. This module uses the YANG model to define the -YANG Remote Processing Call (RPC) and data model, in other words, -the input and output parameters for each action. The Provider module -is responsible for validating the RPC input and for rejecting any -malformed input. After successful validation, the APPC Provider -calls the Dispatcher to continue the request processing. - -LCM API -~~~~~~~ - -The APPC exposes an HTTP API to support the Life Cycle Management -(LCM) commands sent from ONAP components such as SO, SDC, and the -Portal. These commands enable the components to request APPC to -perform actions such as to control, modify, start, or stop virtual -applications and/or their components.  - -A virtual application is composed of the following layers. A Life -Cycle Management command may affect any number of these layers. - -- Virtual Network Function (VNF) - -- Virtual Network Function Component (VNFC) - -- Virtual Machine (VM) - -APP-C supports two types of LCM requests, as described below. - -**Note:** For further information about LCM API, including details of -all the commands currently supported in APP-C and examples of the -request and response format see the ONAP Application Controller (APPC) API Guide.  - -LCM over REST -^^^^^^^^^^^^^^ - -LCM command requests over REST are sent to the APPC using an HTTP -POST request. APPC returns one or more responses for each LCM -request.  - -The APP-C LCM API provides a POST HTTP API endpoint per command.  - -An **asynchronous** command, containing an authorized and valid -request, results in at least two discrete response events: - -- an ACCEPT (a synchronous HTTP response) to indicate that the request - is accepted and will be processed, and - -- a final asynchronous response for the command containing an execution - status is sent via DMaaP - -An unauthorized or invalid request would result in a single -ERROR response.  - -For commands such as Restart, Start, and Stop, the asynchronous response -is sent over DMaaP. - -A **synchronous** command, for example Lock or Unlock, results in a -single response, which is either SUCCESS or ERROR. For this type of -request, the first response is a synchronous HTTP response.. - -For the ONAP Amsterdam release, APPC supports the HTTPS protocol, whereas the plain -HTTP requests are blocked.. - -Endpoint format:  - -``://:/restconf/operations/appc-provider-lcm:`` - -LCM over Message Bus (DMaaP) -^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -APPC is capable of receiving LCM command requests as messages on the -DMaaP bus. In this case, APPC returns one or more responses for each LCM -request, similar to LCM over REST, while both are communicated over -DMaaP. - -Configure the Read/Write topics for the DMaaP as described in APPC -Deployment, APPC Available Properties. - -APPC client library, embedded into APPC client’s (for example, SO) code, -intends to simplify communication over DMaaP by eliminating topic -provisioning at the client site. Refer to -http://onap.readthedocs.io/en/latest/ for more details on the APPC -Client Library. - -For further information about the request and response format, see -the APPC API Guide at http://onap.readthedocs.io/en/latest/ - -Dispatcher -~~~~~~~~~~ - -The APPC Dispatcher component processes requests received by the Request -Handler from other ECOMP components. The Dispatcher checks the -conditions are sufficient for performing the request and selects the -correct Direct Graph (DG) workflow for execution or rejects the request. -When the DG execution is complete, the Dispatching function is -responsible for notifying the initiator of the operation with the -request execution result (Success/Error) and updates the VNF -Orchestration state in Active and Available Inventory (A&AI). - -The detailed responsibilities of the Dispatcher are as follows: - -- Upon receiving the operation request, the Dispatcher performs the - synchronous part of the execution: - - - Starts the operation's time-to-live countdown - - - Queries A&AI to get the VNF type and its current orchestration - state - - - Checks VNF\_type-specific rules in the LCM State machine for - whether to allow or reject the requested command execution - - - Allocates and initiates an appropriate DG workflow by invoking the - Service Logic Interpreter (SLI) framework to start the - asynchronous part of the execution - - - Returns a response to the initiator: OK or reject (for example, if - the State Machine blocks the operation, no DG or time-to-live, or - bad parameters) - - - If the operation is rejected, the Dispatcher generates an - appropriate Audit log for the Event and Error Logging Framework - (EELF) and the Local Event Journal - -- Upon workflow completion, the Dispatcher: - - - Receives the execution results from the DG from the SLI framework - - - Publishes the execution result over DMaaP (success or error) - - - Updates VNF status in A&AI - - - Generates an Audit log for EELF and Local Event Journal - -Request Handler -^^^^^^^^^^^^^^^ - -The Request Handler manages incoming requests and locks APPC for new -requests, as needed for operations with a specific command execution -sequences. - -Lifecycle Management -^^^^^^^^^^^^^^^^^^^^ - -The Lifecycle Management VNF State Machine enables the Dispatching -function to determine the validity of the requested operation (desired -state) as a function of the current VNF state, acquired from the A&AI. -The State Machine maintains its data (states and valid operations) -in-memory. At the point of APPC initialization, the State Machine -constructs a matrix based on the metadata of the current operation and -the valid desired state.  - -Command Executor -^^^^^^^^^^^^^^^^ - -Manages command execution queue. - -State Machine -~~~~~~~~~~~~~ - -The VNF State machine enables the Dispatching function to determine -the validity of the requested operation (desired state) as a -function of the current VNF state, acquired from the A&AI. The State -machine maintains its data (states and valid operations) in-memory. -At the point of APP-C initialization, the State Machine constructs a -matrix based on the metadata of the current operation and the valid -desired state.  - -The Service Logic Interpreter (SLI) Framework -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -The SLI framework is responsible for executing Directed Graphs (DGs). -The Dispatcher invokes the SLI framework to execute a specific DG, based -on the input action. The SLI executes the DG and the sub-DG and returns -a success or failure response to the caller along with the context -variables used to exchange data with the calling body (for example, the -Dispatcher). The caller can use the SLI context to specify data required -for DG execution. The DG returns the same context when execution -completes. - -Currently, there is a combination of input action specific and/or VNF -type specific DG’s as well as a DGOrchestrator DG which is action and -VNF type agnostic. The DGOrchestrator approach consists of the -following: - -- DGOrchestrator DG which: - - - Accepts request from the Dispatcher and converts it into DG - context format - - - Calls A&AI to retrieve the inventory for the VNF instance - - - Calls a Sequence Generator for start/stop actions which generates - a workflow sequence containing a set of start or stop VM requests - - - Auto-generates a workflow for other requests with a single step - - - Executes each step in the workflow by invoking DG’s to interact - with the VNF, OpenStack, or Ansible/Chef servers. These DG’s which - are specific to the protocol and possibly action. Some DG’s may - update A&AI (such as for Configure) or retrieve the VNF running - configuration. - - - Returns success/failure status to the Dispatcher. - -In the future, all action/VNF type specific DG’s will be migrated to the -DGOrchestrator approach. - -The following diagram shows the Amsterdam Release DGOrchestrator -architecture - - |image6| - -Westbound Layer -~~~~~~~~~~~~~~~ - -A&AI -^^^^ - - A&AI is an ONAP component, which maintains information about VNF - instances. APPC uses A&AI as a source of the true VNF status, - topology and operational data. In addition, at the end of each - operation, APPC updates the VNF changes that result from the - operation: for example, VNFC record(s) are added after - configuration. The VNF orchestration status is not updated for - read-only operations such as Sync or Audit. In the case of the VNF - Terminate operation, APPC removes the terminated VNF from A&AI by - deleting its Virtual Machines (VMs).  - - The Dispatching function and operation-specific DGs manage access to - the A&AI using the A&AI Adapter.   - -Southbound Layer -~~~~~~~~~~~~~~~~ - -Southbound VNF Adapters -^^^^^^^^^^^^^^^^^^^^^^^ - - APPC uses several adapters to communicate with VNFs. The Interface - as a Service (IAAS) adapter is part of the OpenDayLight (ODL) - platform, while other adapters have been added by the ONAP - development. - -Restconf Adapter -^^^^^^^^^^^^^^^^^ - - The Adapter is responsible for configuration tasks, using JSON - format, for VNFs supporting Restconf API. - -**Using the Restconf Adapter** - The restconf adapter is normally called from a directed graph. - An "execute" node block should be used in the directed graph to - the "org.onap.appc.adapter.rest.RestAdapter" plug-in. There are - several methods available to use: - -- commonGet -- commonDelete -- commonPost -- commonPut - -There are several parameters that the RestAdapter plug-in takes - -org.onap.appc.instance.URI - The url that the rest request will be made to -org.onap.appc.instance.requestBody - The body of the rest request -org.onap.appc.instance.headers - The header of the rest request -org.onap.appc.instance.haveHeader - true/false value which specifies if a header is present. - (Should be set to "true" if the org.onap.appc.instance.headers - parameter is defined, or set to "false" if the - headers parameter is not defined) - -There are several parameters returned back to the DG from the RestAdapter - -org.onap.rest.result.code - An http code representing if the request completed. Will always be 200 - if the request completes. See the below parameter for the exact http code - that gets returned. -org.onap.rest.agent.result.code - The http code returned from the rest request. -org.onap.rest.agent.result.message - The status or body returned from the rest request. - -An example execute node: - -:: - - - - - - - - - -Netconf Adapter -^^^^^^^^^^^^^^^ - - The Adapter is responsible for configuration tasks, using XML - format, for VNFs supporting Netconf API. - -IAAS Adapter  -^^^^^^^^^^^^^ - - The IAAS Adapter connects APPC with the OpenStack controllers to - perform various operations on VMs and VNFs such as Restart, Migrate, - and Rebuild. The IAAS Adapter integrates as a DG plugin, while the - DGs call the services exposed by the adapter. - -SSH (XML/CLI) Adapter -^^^^^^^^^^^^^^^^^^^^^ - - A custom adapter that enables connection to a VNF using an SSH - session. It is designed to support CLI and XML protocols, including - Netconf. It is used to load configurations and retrieve the running - configuration. - -Chef Adaptor -^^^^^^^^^^^^ - - This adaptor incorporates a client for an external Chef server, - which connects to VNF NB APIs. The adaptor enables APPC to operate - cookbooks (Chef recipes) to perform various LCM operations over - VNFs, connected to the Chef server. - -Ansible Adapter -^^^^^^^^^^^^^^^ - - This adaptor incorporates a client for an external Ansible server, - which connects to VNF NB APIs. The adaptor enables APPC to operate - playbooks to perform various LCM operations over VNFs connected to - the Ansible server. - -Cross Cutting Components -~~~~~~~~~~~~~~~~~~~~~~~~ - -The Cross Cutting Component services operate across all APPC modules. - -Configuration -^^^^^^^^^^^^^ - -Used to configure operational parameters of APPC modules based on -function-specific configuration files, for example: - -- ``log4j.properties`` for the logging service - -- ``appc.properties`` for core APPC-related configuration - -- ``dblib.properties`` for managing APPC database-related configuration - -- ``aaiclient.properties`` for managing A&AI-related configuration - -KPI Service -^^^^^^^^^^^ - -This Cross Cutting component manages KPI measurement, storage and -reporting. - -Enable matrix logs to log the number of hits of the configured method of -APPC, by configuring the following properties in ``appc.properties:``:: - - metric.enabled= - schedule.policy.metric.start.time=