--- /dev/null
+.. ============LICENSE_START==========================================\r
+.. ===================================================================\r
+.. Copyright © 2017 AT&T Intellectual Property. All rights reserved.\r
+.. ===================================================================\r
+.. Licensed under the Creative Commons License, Attribution 4.0 Intl. (the "License");\r
+.. you may not use this documentation except in compliance with the License.\r
+.. You may obtain a copy of the License at\r
+.. \r
+.. https://creativecommons.org/licenses/by/4.0/\r
+.. \r
+.. Unless required by applicable law or agreed to in writing, software\r
+.. distributed under the License is distributed on an "AS IS" BASIS,\r
+.. WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.\r
+.. See the License for the specific language governing permissions and\r
+.. limitations under the License.\r
+.. ============LICENSE_END============================================\r
+.. ECOMP is a trademark and service mark of AT&T Intellectual Property.\r
+\r
+========================================\r
+Application Controller (APPC) User Guide\r
+========================================\r
+\r
+APPC Overview and Architecture\r
+==============================\r
+The Application Controller (APPC) is one of the components of the ONAP\r
+platform. It is responsible for handling the Life Cycle Management (LCM)\r
+of Virtual Network Functions (VNFs).\r
+\r
+This document provides an overview of the APPC components that enable\r
+the LCM operations.\r
+\r
+Implementation\r
+--------------\r
+The APPC infrastructure is implemented on virtual machines in an\r
+OpenStack cloud in the Amsterdam release. APPC is created on top of the OpenDaylight (ODL)\r
+platform\r
+\r
+The following diagram represents a non-redundant APP-C deployment.\r
+\r
+|image0|\r
+\r
+Features\r
+--------\r
+The APPC HTTP API supports Life Cycle Management (LCM) commands,\r
+allowing users to manage virtual applications and their components via\r
+other ONAP components. Refer to Architecture section for further\r
+details.\r
+\r
+Interface\r
+---------\r
+The Application Controller Dashboard interacts with the controller\r
+using REST APIs and performs actions on VNF/VNFC/VMs, such as snapshot,\r
+lock, sync, and health-check.\r
+\r
+Dashboard\r
+~~~~~~~~~\r
+\r
+To open the Application Controller dashboard, go to:\r
+\r
+|image1|\r
+\r
+Navigate to the available LCM commands by clicking on\r
+ **appc-provider-lcm**:\r
+\r
+|image2|\r
+\r
+Click on the URI of the desired action to open a frame with information\r
+about the action and an option to try it out. For example, to send the\r
+action, add the request body as the input parameter value, and click\r
+**Try it out!**\r
+\r
+The following figure shows an example body of a LCM restart request:\r
+\r
+|image3|\r
+\r
+If the request is accepted, you should see the following response:\r
+\r
+|image4|\r
+\r
+APPC Architecture \r
+-----------------\r
+\r
+This section discusses the APPC internal components in detail.\r
+\r
+**APPC High Level Architecture**\r
+\r
+|image5|\r
+\r
+Northbound REST Layer\r
+~~~~~~~~~~~~~~~~~~~~~\r
+\r
+This layer is responsible for interfacing with APPC clients, such as SO\r
+or SDC and others, exposing YANG-based API via REST HTTP and/or DMaaP\r
+messaging (see the Interfaces Summary section for details). In addition,\r
+it exposes APPC OAM (Operation Administration Management) APIs, enabling\r
+ONAP Operations Manager (OOM) or TechOps portal to perform APPC\r
+lifecycle operations\r
+\r
+APPC Provider\r
+~~~~~~~~~~~~~\r
+\r
+The APPC Provider module exposes the endpoints for each action\r
+supported by APPC. This module uses the YANG model to define the\r
+YANG Remote Processing Call (RPC) and data model, in other words,\r
+the input and output parameters for each action. The Provider module \r
+is responsible for validating the RPC input and for rejecting any\r
+malformed input. After successful validation, the APPC Provider\r
+calls the Dispatcher to continue the request processing.\r
+\r
+LCM API\r
+~~~~~~~\r
+\r
+The APPC exposes an HTTP API to support the Life Cycle Management\r
+(LCM) commands sent from ONAP components such as SO, SDC, and the\r
+Portal. These commands enable the components to request APPC to\r
+perform actions such as to control, modify, start, or stop virtual\r
+applications and/or their components. \r
+\r
+A virtual application is composed of the following layers. A Life\r
+Cycle Management command may affect any number of these layers.\r
+\r
+- Virtual Network Function (VNF)\r
+\r
+- Virtual Network Function Component (VNFC)\r
+\r
+- Virtual Machine (VM)\r
+\r
+APP-C supports two types of LCM requests, as described below.\r
+\r
+**Note:** For further information about LCM API, including details of\r
+all the commands currently supported in APP-C and examples of the\r
+request and response format see the ONAP Application Controller (APPC) API Guide. \r
+\r
+LCM over REST \r
+^^^^^^^^^^^^^^\r
+\r
+LCM command requests over REST are sent to the APPC using an HTTP\r
+POST request. APPC returns one or more responses for each LCM\r
+request. \r
+\r
+The APP-C LCM API provides a POST HTTP API endpoint per command. \r
+\r
+An **asynchronous** command, containing an authorized and valid\r
+request, results in at least two discrete response events:\r
+\r
+- an ACCEPT (a synchronous HTTP response) to indicate that the request\r
+ is accepted and will be processed, and\r
+\r
+- a final asynchronous response for the command containing an execution\r
+ status is sent via DMaaP\r
+\r
+An unauthorized or invalid request would result in a single\r
+ERROR response. \r
+\r
+For commands such as Restart, Start, and Stop, the asynchronous response\r
+is sent over DMaaP.\r
+\r
+A **synchronous** command, for example Lock or Unlock, results in a\r
+single response, which is either SUCCESS or ERROR. For this type of\r
+request, the first response is a synchronous HTTP response..\r
+\r
+For this release, APPC supports the HTTPS protocol, whereas the plain\r
+HTTP requests are blocked..\r
+\r
+Endpoint format: \r
+\r
+``<http-protocol>://<appc-ip>:<appc-api-port>/restconf/operations/appc-provider-lcm:<command-name>``\r
+\r
+LCM over Message Bus (DMaaP)\r
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^\r
+\r
+APPC is capable of receiving LCM command requests as messages on the\r
+DMaaP bus. In this case, APPC returns one or more responses for each LCM\r
+request, similar to LCM over REST, while both are communicated over\r
+DMaaP.\r
+\r
+Configure the Read/Write topics for the DMaaP as described in APPC\r
+Deployment, APPC Available Properties.\r
+\r
+APPC client library, embedded into APPC client’s (for example, SO) code,\r
+intends to simplify communication over DMaaP by eliminating topic\r
+provisioning at the client site. Refer to\r
+http://onap.readthedocs.io/en/latest/ for more details on the APPC\r
+Client Library.\r
+\r
+For further information about the request and response format, see\r
+the APPC API Guide at http://onap.readthedocs.io/en/latest/\r
+\r
+Dispatcher\r
+~~~~~~~~~~\r
+\r
+The APPC Dispatcher component processes requests received by the Request\r
+Handler from other ECOMP components. The Dispatcher checks the\r
+conditions are sufficient for performing the request and selects the\r
+correct Direct Graph (DG) workflow for execution or rejects the request.\r
+When the DG execution is complete, the Dispatching function is\r
+responsible for notifying the initiator of the operation with the\r
+request execution result (Success/Error) and updates the VNF\r
+Orchestration state in Active and Available Inventory (A&AI).\r
+\r
+The detailed responsibilities of the Dispatcher are as follows:\r
+\r
+- Upon receiving the operation request, the Dispatcher performs the\r
+ synchronous part of the execution:\r
+\r
+ - Starts the operation's time-to-live countdown\r
+\r
+ - Queries A&AI to get the VNF type and its current orchestration\r
+ state\r
+\r
+ - Checks VNF\_type-specific rules in the LCM State machine for\r
+ whether to allow or reject the requested command execution\r
+\r
+ - Allocates and initiates an appropriate DG workflow by invoking the\r
+ Service Logic Interpreter (SLI) framework to start the\r
+ asynchronous part of the execution\r
+\r
+ - Returns a response to the initiator: OK or reject (for example, if\r
+ the State Machine blocks the operation, no DG or time-to-live, or\r
+ bad parameters)\r
+\r
+ - If the operation is rejected, the Dispatcher generates an\r
+ appropriate Audit log for the Event and Error Logging Framework\r
+ (EELF) and the Local Event Journal\r
+\r
+- Upon workflow completion, the Dispatcher:\r
+\r
+ - Receives the execution results from the DG from the SLI framework\r
+\r
+ - Publishes the execution result over DMaaP (success or error)\r
+\r
+ - Updates VNF status in A&AI\r
+\r
+ - Generates an Audit log for EELF and Local Event Journal\r
+\r
+Request Handler\r
+^^^^^^^^^^^^^^^\r
+\r
+The Request Handler manages incoming requests and locks APPC for new\r
+requests, as needed for operations with a specific command execution\r
+sequences.\r
+\r
+Lifecycle Management\r
+^^^^^^^^^^^^^^^^^^^^\r
+\r
+The Lifecycle Management VNF State Machine enables the Dispatching\r
+function to determine the validity of the requested operation (desired\r
+state) as a function of the current VNF state, acquired from the A&AI.\r
+The State Machine maintains its data (states and valid operations)\r
+in-memory. At the point of APPC initialization, the State Machine\r
+constructs a matrix based on the metadata of the current operation and\r
+the valid desired state. \r
+\r
+Command Executor\r
+^^^^^^^^^^^^^^^^\r
+\r
+Manages command execution queue.\r
+\r
+State Machine\r
+~~~~~~~~~~~~~\r
+\r
+The VNF State machine enables the Dispatching function to determine\r
+the validity of the requested operation (desired state) as a\r
+function of the current VNF state, acquired from the A&AI. The State\r
+machine maintains its data (states and valid operations) in-memory.\r
+At the point of APP-C initialization, the State Machine constructs a\r
+matrix based on the metadata of the current operation and the valid\r
+desired state. \r
+\r
+The Service Logic Interpreter (SLI) Framework\r
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\r
+\r
+The SLI framework is responsible for executing Directed Graphs (DGs).\r
+The Dispatcher invokes the SLI framework to execute a specific DG, based\r
+on the input action. The SLI executes the DG and the sub-DG and returns\r
+a success or failure response to the caller along with the context\r
+variables used to exchange data with the calling body (for example, the\r
+Dispatcher). The caller can use the SLI context to specify data required\r
+for DG execution. The DG returns the same context when execution\r
+completes.\r
+\r
+Currently, there is a combination of input action specific and/or VNF\r
+type specific DG’s as well as a DGOrchestrator DG which is action and\r
+VNF type agnostic. The DGOrchestrator approach consists of the\r
+following:\r
+\r
+- DGOrchestrator DG which:\r
+\r
+ - Accepts request from the Dispatcher and converts it into DG\r
+ context format\r
+\r
+ - Calls A&AI to retrieve the inventory for the VNF instance\r
+\r
+ - Calls a Sequence Generator for start/stop actions which generates\r
+ a workflow sequence containing a set of start or stop VM requests\r
+\r
+ - Auto-generates a workflow for other requests with a single step\r
+\r
+ - Executes each step in the workflow by invoking DG’s to interact\r
+ with the VNF, OpenStack, or Ansible/Chef servers. These DG’s which\r
+ are specific to the protocol and possibly action. Some DG’s may\r
+ update A&AI (such as for Configure) or retrieve the VNF running\r
+ configuration.\r
+\r
+ - Returns success/failure status to the Dispatcher.\r
+\r
+In the future, all action/VNF type specific DG’s will be migrated to the\r
+DGOrchestrator approach.\r
+\r
+The following diagram shows the Amsterdam Release DGOrchestrator\r
+architecture\r
+\r
+ |image6|\r
+\r
+Westbound Layer\r
+~~~~~~~~~~~~~~~\r
+\r
+A&AI\r
+^^^^\r
+\r
+ A&AI is an ONAP component, which maintains information about VNF\r
+ instances. APPC uses A&AI as a source of the true VNF status,\r
+ topology and operational data. In addition, at the end of each\r
+ operation, APPC updates the VNF changes that result from the\r
+ operation: for example, VNFC record(s) are added after\r
+ configuration. The VNF orchestration status is not updated for\r
+ read-only operations such as Sync or Audit. In the case of the VNF\r
+ Terminate operation, APPC removes the terminated VNF from A&AI by\r
+ deleting its Virtual Machines (VMs). \r
+\r
+ The Dispatching function and operation-specific DGs manage access to\r
+ the A&AI using the A&AI Adapter. \r
+\r
+Southbound Layer\r
+~~~~~~~~~~~~~~~~\r
+\r
+Southbound VNF Adapters\r
+^^^^^^^^^^^^^^^^^^^^^^^\r
+\r
+ APPC uses several adapters to communicate with VNFs. The Interface\r
+ as a Service (IAAS) adapter is part of the OpenDayLight (ODL)\r
+ platform, while other adapters have been added by the ONAP\r
+ development.\r
+\r
+Restconf Adapter \r
+^^^^^^^^^^^^^^^^^\r
+\r
+ The Adapter is responsible for configuration tasks, using JSON\r
+ format, for VNFs supporting Restconf API.\r
+\r
+Netconf Adapter\r
+^^^^^^^^^^^^^^^\r
+\r
+ The Adapter is responsible for configuration tasks, using XML\r
+ format, for VNFs supporting Netconf API.\r
+\r
+IAAS Adapter \r
+^^^^^^^^^^^^^\r
+\r
+ The IAAS Adapter connects APPC with the OpenStack controllers to\r
+ perform various operations on VMs and VNFs such as Restart, Migrate,\r
+ and Rebuild. The IAAS Adapter integrates as a DG plugin, while the\r
+ DGs call the services exposed by the adapter.\r
+\r
+SSH (XML/CLI) Adapter\r
+^^^^^^^^^^^^^^^^^^^^^\r
+\r
+ A custom adapter that enables connection to a VNF using an SSH\r
+ session. It is designed to support CLI and XML protocols, including\r
+ Netconf. It is used to load configurations and retrieve the running\r
+ configuration.\r
+\r
+Chef Adaptor\r
+^^^^^^^^^^^^\r
+\r
+ This adaptor incorporates a client for an external Chef server,\r
+ which connects to VNF NB APIs. The adaptor enables APPC to operate\r
+ cookbooks (Chef recipes) to perform various LCM operations over\r
+ VNFs, connected to the Chef server.\r
+\r
+Ansible Adapter\r
+^^^^^^^^^^^^^^^\r
+\r
+ This adaptor incorporates a client for an external Ansible server,\r
+ which connects to VNF NB APIs. The adaptor enables APPC to operate\r
+ playbooks to perform various LCM operations over VNFs connected to\r
+ the Ansible server.\r
+\r
+Cross Cutting Components\r
+~~~~~~~~~~~~~~~~~~~~~~~~\r
+\r
+The Cross Cutting Component services operate across all APPC modules.\r
+\r
+Configuration\r
+^^^^^^^^^^^^^\r
+\r
+Used to configure operational parameters of APPC modules based on\r
+function-specific configuration files, for example:\r
+\r
+- ``log4j.properties`` for the logging service\r
+\r
+- ``appc.properties`` for core APPC-related configuration\r
+\r
+- ``dblib.properties`` for managing APPC database-related configuration\r
+\r
+- ``aaiclient.properties`` for managing A&AI-related configuration\r
+\r
+KPI Service\r
+^^^^^^^^^^^\r
+\r
+This Cross Cutting component manages KPI measurement, storage and\r
+reporting.\r
+\r
+Enable matrix logs to log the number of hits of the configured method of\r
+APPC, by configuring the following properties in ``appc.properties:``::\r
+\r
+ metric.enabled=<true>\r
+ schedule.policy.metric.start.time=<time value in hhmmss>\r
+ schedule.policy.metric.period = 60(interval in seconds)\r
+\r
+Security Service\r
+^^^^^^^^^^^^^^^^\r
+\r
+This component implements AAF (Authentication and Authorization\r
+Framework) for APPC API security. The user provides a user name and\r
+password in the request that will be validated against centralize AAF.\r
+[Note: For Amsterdam Releasse, AAF is not used]\r
+\r
+Logging Service\r
+^^^^^^^^^^^^^^^\r
+\r
+Implements EELF (Event and Error Logging Framework) to manage and\r
+generate logs (refer to Logging section).\r
+\r
+Data Access Service\r
+^^^^^^^^^^^^^^^^^^^\r
+\r
+Provides access to the internal data store.\r
+\r
+Transactions store\r
+~~~~~~~~~~~~~~~~~~\r
+\r
+For each operation request procedure that completes or terminates,\r
+APPC generates and stores an accurate transaction record in its\r
+internal database, including:\r
+\r
+- Timestamp\r
+\r
+- Request ID\r
+\r
+- Start time\r
+\r
+- End time\r
+\r
+- VF\_ID\r
+\r
+- VF\_type\r
+\r
+- Sub-component (optional) e.g. VFC\_ID/VM UUID\r
+\r
+- Operation: for example Start, Configure, etc.\r
+\r
+- Result: Success/Error code and description, as published to the\r
+ initiator\r
+\r
+Interfaces Summary\r
+~~~~~~~~~~~~~~~~~~\r
+\r
++-------------------+------------+-------------------------+-------------------+-------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+\r
+| **Source** | **Flow** | **Destination** | **Service** | **Port** | **Purpose / Comments** |\r
++===================+============+=========================+===================+=============+============================================================================================================================================================================+\r
+| APPC | -> | A&AI | REST | 8443 | APPC retrieves and updates the VNF data in AAI. |\r
++-------------------+------------+-------------------------+-------------------+-------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+\r
+| APPC | -> | SLI | Java (internal) | N/A | APPC sends the LCM API request to SLI for DG execution |\r
++-------------------+------------+-------------------------+-------------------+-------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+\r
+| APPC | -> | South-bound Adapters | Java (internal) | N/A | APPC interacts with southbound adapters for VNF Lifecycle Management Actions |\r
++-------------------+------------+-------------------------+-------------------+-------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+\r
+| APPC | -> | NETCONF | NETCONF | 830 or 22 | NETCONF Adapter communicates on port 830 (default) or port 22 (SSH – if set up) |\r
++-------------------+------------+-------------------------+-------------------+-------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+\r
+| APPC | -> | Chef Server | HTTP/HTTPS | 80/443 | Chef adapter communicate on port 80 (HTTP) or port 443 (HTTPS) |\r
++-------------------+------------+-------------------------+-------------------+-------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+\r
+| APPC | -> | Ansible Server | HTTP | 8000 | Port 8000 is used for communication between the APPC Ansible Adaptor and the Ansible Server. |\r
++-------------------+------------+-------------------------+-------------------+-------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+\r
+| APPC | -> | MySQL | Java (internal) | 3306 | |\r
++-------------------+------------+-------------------------+-------------------+-------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+\r
+| APPC | -> | DG Builder | Java (internal) | 3000 | |\r
++-------------------+------------+-------------------------+-------------------+-------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+\r
+| APPC | -> | MD-SAL, Apidoc, Karaf | Java (internal) | 8282 | |\r
++-------------------+------------+-------------------------+-------------------+-------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+\r
+| APPC | -> | DMaaP | JMS | 3904 | APPC sends the Asynchronous responses and Failure events to DMaaP Message Bus |\r
++-------------------+------------+-------------------------+-------------------+-------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+\r
+| Portal,SO, DCAE | -> | APPC | REST/DMaaP | 3904 | APPC receives LCM commands from and makes updates to ONAP components such as the Portal, MSO, and DCAE |\r
++-------------------+------------+-------------------------+-------------------+-------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+\r
+| SDC | -> | APPC | DMaaP | 3904 | APPC requests and receives notifications from SDC for VNF License Artifacts and TOSCA dependency models. |\r
++-------------------+------------+-------------------------+-------------------+-------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+\r
+| APPC | -> | DCAE | DMaaP | 3904 | APPC sends intermediate messages to DCAE. Long-running operations such as Start, Restart, Stop, and Terminate generate intermediate success/failure messages per VNFC. |\r
++-------------------+------------+-------------------------+-------------------+-------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+\r
+| OOM | -> | APPC | DMaaP | 3904 | APPC receives operational commands: Start, Graceful Stop. |\r
+| | | | | | APPC reports: status, KPIs. |\r
++-------------------+------------+-------------------------+-------------------+-------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+\r
+\r
+APPC Deployment \r
+================\r
+\r
+Refer to the APPC Deployment documentation at\r
+http://onap.readthedocs.io/en/latest/submodules/appc/deployment.git/docs/index.html\r
+\r
+Application Controller VNF Onboarding\r
+=====================================\r
+\r
+LCM Command Execution Overview\r
+------------------------------\r
+\r
+The Application Controller assumes that the A&AI instance it is\r
+configured with contains all the information it needs about\r
+VNF/VNFC/VMs, otherwise any request by the user to perform an action\r
+on a VNF will fail. The Application Controller uses a variety of SQL\r
+tables in order to perform actions on a VNF, all of which are\r
+described in Creation of DGs\r
+\r
+DGs are created using the Direct Graph Builder - Node Red graphical\r
+utility for DGs creation. DGs are then stored as XML files and loaded to\r
+APPC MySQL database. The DGs invoke the execution of Java code from\r
+different nodes.\r
+\r
+DGs are resolved according to LCM Action, API version, VNF Type, and VNF\r
+Version.\r
+\r
+The SLI framework is responsible for executing the DGs.\r
+\r
+Data Setup. \r
+~~~~~~~~~~~~\r
+\r
+Initially, Application Controller should have a set of DGs designed\r
+for the specific VNF type. These DGs are stored in the SVC\_LOGIC\r
+table.\r
+\r
+After a user sends an action request to the controller, the\r
+Application Controller uses the VNF\_DG\_MAPPING table to map the\r
+requested action to a specific DG. If the mapping was successful,\r
+the input body is validated and the user receives a synchronous\r
+response containing an Accept or a Reject message to indicate\r
+whether the request was rejected or whether it was accepted and the\r
+controller initiated the DG flow.\r
+\r
+During the execution of a DG, the controller may use one or more SQL\r
+tables to fetch or store data. For example, in order to perform a\r
+ConfigModify action, the controller needs to fetch a username and\r
+password to connect to the VNF and change its configuration.\r
+\r
+ALL tables used during DG execution are described below.\r
+\r
+Request execution\r
+-----------------\r
+\r
+Following initial request validation, APPC queries the A&AI inventory to\r
+acquire all the required information regarding topology of VNF/VNFC/VMs,\r
+operational status and operational data of the requested VNF instance. A\r
+missing target VF instance or any missing mandatory parameter in A&AI\r
+generate a rejection.\r
+\r
+After acquiring the VNF type from A&AI, APPC uses the VNF\_DG\_MAPPING\r
+table to map the requested action to a specific DG. No such DG located\r
+in the table generates a Reject response to the user.\r
+\r
+The Dispatcher state machine applies operation policies. A policy\r
+allowing execution generates an Accept response to the user. Not\r
+allowing execution generates a Reject response.\r
+\r
+If the first two steps were successful, the controller initiates the\r
+appropriate DG.\r
+\r
+During the execution of a DG, the controller may use one or more SQL\r
+tables to fetch or store data. For example, to perform a ConfigModify\r
+action, the controller needs to fetch a username and password to connect\r
+to the VNF and change its configuration.\r
+\r
+`Data Setup <#_Data_Setup>`__ describes the tables used during DG\r
+execution.\r
+\r
+If APPC is forced stopped while it is executing an LCM request, it might\r
+take some time to terminate all the threads that are being executed. In\r
+addition, the old threads might start to execute again once the APPC is\r
+restarted. The time when these treads start to execute again even after\r
+an APPC restart is dependent on the LCM request executed by the threads\r
+in the LCM queue and the ThreadPool size. To avoid this, it is\r
+recommended that:\r
+\r
+- Start APPC only after a while to ensure that the interrupted threads\r
+ are not executed again.\r
+\r
+- Do not execute the OAM-Forceful Stop command if the system is\r
+ executing an LCM request. Let the system operate in Maintenance mode.\r
+\r
+ 1. .. rubric:: Creation of DGs\r
+ :name: creation-of-dgs\r
+\r
+DGs are created using the Direct Graph Builder - Node Red graphical\r
+utility for DGs creation. DGs are then stored as XML files and loaded to\r
+APPC MySQL database. The DGs invoke the execution of Java code from\r
+different nodes.\r
+\r
+At runtime, DGs are resolved according to LCM Action, API version, VNF\r
+Type, and VNF Version.\r
+\r
+The SLI framework is responsible for executing the DGs.\r
+\r
+Data Setup\r
+----------\r
+\r
+APPC uses MySQL database as a persistent store. This section describes\r
+the tables in general and the tables that require data to be set up\r
+before sending a request.\r
+\r
+SVC\_LOGIC Table\r
+~~~~~~~~~~~~~~~~\r
+\r
+SVC\_LOGIC table stores all NodeRed DGs invoked by actions executed by\r
+APPC. The SLI framework uses this table for running the DG. If the DG\r
+does not exist in this table, the SLI framework returns a 'DG not found'\r
+error.\r
+\r
+SVC\_LOGIC Parameters\r
+^^^^^^^^^^^^^^^^^^^^^\r
+\r
++----------------------+----------------------+\r
+| **Parameter Name** | **Example Values** |\r
++======================+======================+\r
+| **module** | APPC |\r
++----------------------+----------------------+\r
+| **rpc** | Generic\_Audit |\r
++----------------------+----------------------+\r
+| **version** | 2.0.0 |\r
++----------------------+----------------------+\r
+| **mode** | sync |\r
++----------------------+----------------------+\r
+| **active** | N |\r
++----------------------+----------------------+\r
+| **graph** | <BLOB> |\r
++----------------------+----------------------+\r
+\r
+**module, rpc, version**\r
+\r
+The ``module``, ``rpc``, and ``version`` parameters uniquely identify a Directed\r
+Graph (DG). The SLI framework uses these three parameters to invoke a DG\r
+or sub-DG. By convention, for the main DG, rpc is a combination of 'VNF\r
+type' (the generic type applied to all VNFs) followed by '\_' and\r
+'action'. This is the default convention; resolution of the DG for\r
+specific actions is handled individually in the relevant forthcoming\r
+sections.\r
+\r
+**mode**\r
+\r
+The DG execution node. This value is set to ‘sync’ for all APPC DGs.\r
+\r
+**active**\r
+\r
+This flag is the value of either 'Y' or 'N'. This flag is only used if\r
+specific version of DG is not mentioned while calling DG. If version of\r
+DG is not mentioned SLI framework will look for DG with active Flag set\r
+to 'Y' and execute it if found.\r
+\r
+**graph**\r
+\r
+This is actual graph invoked by SLI framework. The data type is SQL\r
+BLOB.\r
+\r
+VNF\_DG\_MAPPING\r
+~~~~~~~~~~~~~~~~\r
+\r
+The VNF\_DG\_MAPPING table stores the VNF and its corresponding DG. This\r
+is used by the DG resolver logic of the Dispatcher to map the DG to the\r
+requested action. Only the mapping is stored; the actual DG is stored in\r
+the SVC\_LOGIC table.\r
+\r
+The DG resolver logic uses a combination of action, api\_version and\r
+vnf\_type to retrieve the DG details: dg\_name (rpc column of SVC\_LOGIC\r
+table), dg\_version and dg\_module.\r
+\r
+The module, rpc and version uniquely identify the DG.\r
+\r
+The following assigned priority resolves the VNF DG:\r
+\r
+1. ``action``\r
+\r
+2. ``api_version``\r
+\r
+3. ``vnf_type``\r
+\r
+4. ``vnf_version``\r
+\r
+Blank, null or ‘\*’ values in ``api_version``, ``vnf_type`` and ``vnf_version``\r
+are matched with any values by the DG resolver. For example, a generic\r
+DG which can be invoked on any type of VNF ``vnf_type`` can be blank /\r
+null or \*. The DG resolver logic first tries to match a specific DG,\r
+and if this is not found, then look for a generic match using ‘\*’. For\r
+example as illustrated in the Example values in below table, an entry\r
+for the Test action and vnf\_type VSBG is specific, so it is only used\r
+for VNFs of type VSBG, whereas for the Sync action the same DG is used\r
+for any type of VNF and any version.\r
+\r
+VNF\_DG\_MAPPING Parameters\r
+^^^^^^^^^^^^^^^^^^^^^^^^^^^\r
+\r
++----------------------+----------------------+-----------------+\r
+| **Parameter Name** | **Example Values** |\r
++======================+======================+=================+\r
+| **action** | Test | Sync |\r
++----------------------+----------------------+-----------------+\r
+| **api\_verson** | 2 | |\r
++----------------------+----------------------+-----------------+\r
+| **vnf\_type** | vSBG | |\r
++----------------------+----------------------+-----------------+\r
+| **vnf\_version** | | |\r
++----------------------+----------------------+-----------------+\r
+| **dg\_name** | vSBG\_Test | Generic\_Sync |\r
++----------------------+----------------------+-----------------+\r
+| **dg\_version** | 2.0.0.1 | 2.0.0 |\r
++----------------------+----------------------+-----------------+\r
+| **dg\_module** | APPC | APPC |\r
++----------------------+----------------------+-----------------+\r
+\r
+VNFC\_DG\_MAPPING\r
+~~~~~~~~~~~~~~~~~\r
+\r
+VNFC\_DG\_MAPPING stores the VNFC and its corresponding DG. The DG\r
+resolver logic of the Dispatcher uses this to map the DG to the\r
+requested action. Only the mapping is stored; the actual DG is stored in\r
+the SVC\_LOGIC table.\r
+\r
+The DG resolver logic uses a combination of ``action``, ``api_version``,\r
+``vnf_type``, and ``vnfc_type`` to retrieve the DG details: ``dg_name`` (rpc\r
+column of SVC\_LOGIC table), ``dg_version``, and ``dg_module``.\r
+\r
+The module, rpc and version uniquely identify the DG.\r
+\r
+The following assigned priority resolves the VNF DG:\r
+\r
+1. ``action``\r
+\r
+2. ``api_version``\r
+\r
+3. ``vnf_type``\r
+\r
+4. ``vnfc_type``\r
+\r
+The DG resolver matches blank, null or ‘\*’ values in ``api_version`` ,\r
+``vnf_type`` and ``vnfc_type`` with any values. For example, a generic DG\r
+which can be invoked on any type of VNFC 'vnfc\_type' can be blank /\r
+null or \*. The DG resolver logic first tries to match a specific DG. If\r
+this is not found, the DG resolver looks for a generic match using ‘\*’.\r
+\r
+VNFC\_DG\_MAPPING parameters\r
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^\r
+\r
++----------------------+---------------------+\r
+| **Parameter Name** | **Example Value** |\r
++======================+=====================+\r
+| **action** | |\r
++----------------------+---------------------+\r
+| **api\_version** | |\r
++----------------------+---------------------+\r
+| **vnf\_type** | |\r
++----------------------+---------------------+\r
+| **vnfc\_type** | |\r
++----------------------+---------------------+\r
+| **dg\_name** | |\r
++----------------------+---------------------+\r
+| **dg\_version** | |\r
++----------------------+---------------------+\r
+| **dg\_module** | |\r
++----------------------+---------------------+\r
+\r
+DEVICE\_AUTHENTICATION\r
+~~~~~~~~~~~~~~~~~~~~~~\r
+\r
+The DEVICE\_AUTHENTICATION table stores device authentication\r
+details. It is used by actions such as Audit and Sync which connect\r
+with VNFs. This table stores a record that corresponds to each VNF\r
+type, so ``vnf_type`` is unique.\r
+\r
+Username, password and port\_number are fields corresponding to\r
+``vnf_type``.\r
+\r
+DEVICE\_AUTHENTICATION Parameters\r
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\r
+\r
++----------------------------------+---------------------+\r
+| **Parameter Name** | **Example Value** |\r
++==================================+=====================+\r
+| **device\_authentication\_id** | 41 |\r
++----------------------------------+---------------------+\r
+| **vnf\_type** | vDBE-V |\r
++----------------------------------+---------------------+\r
+| **user\_name** | root |\r
++----------------------------------+---------------------+\r
+| **password** | <password> |\r
++----------------------------------+---------------------+\r
+| **port\_number** | 22 |\r
++----------------------------------+---------------------+\r
+\r
+VNF\_LOCK\_MANAGEMENT\r
+~~~~~~~~~~~~~~~~~~~~~\r
+\r
+The VNF\_LOCK\_MANAGEMENT table is used to persist data for vnf\r
+locking. APPC locks the vnf id when actions start executing on that\r
+vnf id. This table stores vnf\_id i.e. resource\_id along with\r
+owner , expiration\_time or timeout. Before execution of request,\r
+the dispatcher checks if VNF\_ID is already locked by another action\r
+in execution. If VNF\_ID is not locked, the dispatcher will locks it\r
+or else returns a VNF locked error to caller.\r
+\r
+VNF\_LOCK\_MANAGEMENT Parameters\r
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\r
+\r
++----------------------+---------------------+\r
+| **Parameter Name** | **Example Value** |\r
++======================+=====================+\r
+| **resource\_id** | AUDIT\_1652 |\r
++----------------------+---------------------+\r
+| **owner\_id** | vDBE-V |\r
++----------------------+---------------------+\r
+| **updated** | 1474457140000 |\r
++----------------------+---------------------+\r
+| **timeout** | 0 |\r
++----------------------+---------------------+\r
+| **ver** | 22 |\r
++----------------------+---------------------+\r
+\r
+This table do not require any initial setup.\r
+\r
+VNF\_STATE\_MANAGEMENT\r
+~~~~~~~~~~~~~~~~~~~~~~\r
+\r
+The VNF\_STATE\_MANAGEMENT table is used to store the operational state\r
+of VNF\_ID, whether it is stable or unstable. It stores state, owner and\r
+updated time (in milliseconds). This table does not require any initial\r
+setup.\r
+\r
+VNF\_STATE\_MANAGEMENT Parameters\r
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\r
+\r
++----------------------+-------------------------------------+\r
+| **Parameter Name** | **Example Value** |\r
++======================+=====================================+\r
+| **vnf\_if** | ASHISH\_VSBG\_VNFS\_1787 |\r
++----------------------+-------------------------------------+\r
+| **state** | STABLE |\r
++----------------------+-------------------------------------+\r
+| **owner\_id** | ORIG\_1787@REQ\_1787@SUBREQ\_1787 |\r
++----------------------+-------------------------------------+\r
+| **updated** | 1474457140000 |\r
++----------------------+-------------------------------------+\r
+| **timeout** | 0 |\r
++----------------------+-------------------------------------+\r
+| **ver** | 22 |\r
++----------------------+-------------------------------------+\r
+\r
+UPLOAD\_CONFIG\r
+~~~~~~~~~~~~~~\r
+\r
+The UPLOAD\_CONFIG table is used by configuration management actions\r
+such as Audit, Sync, ConfigModify, Terminate, and similar. It stores\r
+device configuration: one row or record corresponds to one VNFC, so\r
+therefore a VNF that has multiple VNFCs has multiple rows in the\r
+table.\r
+\r
+The UPLOAD\_CONFIG table stores configuration as the following\r
+types:\r
+\r
+- ``Current``\r
+\r
+- ``Running``\r
+\r
+- ``Historic``\r
+\r
+The ``config_indicator`` column denotes the type of configuration,\r
+where a null value denotes ``Historic`` configuration. For a single VNFC\r
+there should only be one ``Current`` and one ``Running`` configuration , but\r
+there can be multiple Historic configurations. This table does not\r
+require any initial setup.\r
+\r
+UPLOAD\_CONFIG Parameters\r
+^^^^^^^^^^^^^^^^^^^^^^^^^\r
+\r
++----------------------------+-------------------------+-------------------------+\r
+| **Parameter Name** | **Example Values** |\r
++============================+=========================+=========================+\r
+| **upload\_config\_id** | 63 | 67 |\r
++----------------------------+-------------------------+-------------------------+\r
+| **request\_id** | 3 | REQ\_1690 |\r
++----------------------------+-------------------------+-------------------------+\r
+| **originator\_id** | 12345 | ORIG\_1690 |\r
++----------------------------+-------------------------+-------------------------+\r
+| **service\_description** | abcde | abcde |\r
++----------------------------+-------------------------+-------------------------+\r
+| **action** | ConfigModify | Sync |\r
++----------------------------+-------------------------+-------------------------+\r
+| **upload\_date** | 2016-08-01 14:30:40 | 2016-09-22 12:30:40 |\r
++----------------------------+-------------------------+-------------------------+\r
+| **vnf\_id** | AUDIT\_1767 | AUDIT\_1690 |\r
++----------------------------+-------------------------+-------------------------+\r
+| **vnf\_name** | GET\_RUN\_CONFIG\_VNF | GET\_RUN\_CONFIG\_VNF |\r
++----------------------------+-------------------------+-------------------------+\r
+| **vm\_name** | GET\_RUN\_CONFIG\_VNF | GET\_RUN\_CONFIG\_VNF |\r
++----------------------------+-------------------------+-------------------------+\r
+| **vnf\_type** | vDBE-V | vDBE-V |\r
++----------------------------+-------------------------+-------------------------+\r
+| **vnfc\_type** | vDBE-V2 | vDBE-V1 |\r
++----------------------------+-------------------------+-------------------------+\r
+| **host\_ip\_address** | 135.25.69.37 | |\r
++----------------------------+-------------------------+-------------------------+\r
+| **config\_indicator** | Current | Running |\r
++----------------------------+-------------------------+-------------------------+\r
+| **pending\_delete** | | |\r
++----------------------------+-------------------------+-------------------------+\r
+| **content** | Dummy\_current | <Configuration> |\r
++----------------------------+-------------------------+-------------------------+\r
+\r
+DEVICE\_INTERFACE\_PROTOCOL\r
+~~~~~~~~~~~~~~~~~~~~~~~~~~~\r
+\r
+The DEVICE\_INTERFACE\_PROTOCOL table stores the VNF type and\r
+corresponding sub-DG used to get the running configuration of a device.\r
+The 'getRunningConfig' DG, which is a sub-DG called by Audit and Sync\r
+DG, uses this table. It stores the VNF type and corresponding sub-DG,\r
+which are used to get the running configuration of a device. The ``module``\r
+and ``DG_RPC`` are used to identify the DG from the SVC\_LOGIC table. The\r
+``protocol`` is used to store the protocol defined for retrieving\r
+configuration. If a mapping between the VNF type and the DG does not\r
+exist in this table, then actions such as Audit and Sync fail with the\r
+error message 'Device Interfacing DG not available'.\r
+\r
+DEVICE\_INTERFACE\_PROTOCOL Parameters\r
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\r
+\r
++---------------------------------------+--------------------------+\r
+| **Parameter Name** | **Example Value** |\r
++=======================================+==========================+\r
+| **device\_interface\_protocol\_id** | 4 |\r
++---------------------------------------+--------------------------+\r
+| **vnf\_type** | vDBE-V |\r
++---------------------------------------+--------------------------+\r
+| **protocol** | NETCONF-XML |\r
++---------------------------------------+--------------------------+\r
+| **module** | APPC |\r
++---------------------------------------+--------------------------+\r
+| **dg\_rpc** | getDeviceRunningConfig |\r
++---------------------------------------+--------------------------+\r
+\r
+CONFIG FILES\r
+~~~~~~~~~~~~\r
+\r
+The CONFIG\_FILES table is used by the several configuration DGs, using\r
+a legacy configuration API, to store artifacts from SDC, configuration\r
+data from requests, and configurations to be downloaded to VNFs.\r
+\r
+CONFIG\_FILES Parameters\r
+^^^^^^^^^^^^^^^^^^^^^^^^\r
+\r
++-----------------------------+----------------------------+\r
+| **Parameter Name** | **Example Value** |\r
++=============================+============================+\r
+| **config\_file\_id** | 24 |\r
++-----------------------------+----------------------------+\r
+| **external\_version** | |\r
++-----------------------------+----------------------------+\r
+| **data\_source** | Configurator |\r
++-----------------------------+----------------------------+\r
+| **creation\_date** | 6/9/2016 11:16:57 AM |\r
++-----------------------------+----------------------------+\r
+| **service\_instance\_id** | ibcx0001vm001 |\r
++-----------------------------+----------------------------+\r
+| **vnf\_type** | ISBC |\r
++-----------------------------+----------------------------+\r
+| **vnfc\_type** | vISBC - mmc |\r
++-----------------------------+----------------------------+\r
+| **file\_category** | device\_configuration |\r
++-----------------------------+----------------------------+\r
+| **file\_name** | orch\_config.json |\r
++-----------------------------+----------------------------+\r
+| **file\_content** | (contains configuration) |\r
++-----------------------------+----------------------------+\r
+\r
+GET\_CONFIG\_TEMPLATE\r
+~~~~~~~~~~~~~~~~~~~~~\r
+\r
+The GET\_CONFIG\_TEMPLATE table is used by the 'getDeviceRunningConfig'\r
+DG, which is used as a sub-DG for the Audit and Sync actions. It stores\r
+template data corresponding to the VNF type. Template data is only used\r
+when the protocol in DEVICE\_INTERFACING\_PROTOCOL table is set to\r
+'CLI'. Other protocols do not use this table. If Data does not exist in\r
+this table and protocol is set to 'CLI' then DG results in 'Error\r
+getting Template Data'.\r
+\r
+GET\_CONFIG\_TEMPLATE Parameters\r
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\r
+\r
++---------------------------------------+-----------------------------------------+\r
+| **Parameter Name** | **Example Value** |\r
++=======================================+=========================================+\r
+| **get\_config\_template\_id** | 1 |\r
++---------------------------------------+-----------------------------------------+\r
+| **vnf\_type** | Generic |\r
++---------------------------------------+-----------------------------------------+\r
+| **device\_interface\_protocol\_id** | 3 |\r
++---------------------------------------+-----------------------------------------+\r
+| **xml\_processing** | |\r
++---------------------------------------+-----------------------------------------+\r
+| **xml\_protocol** | |\r
++---------------------------------------+-----------------------------------------+\r
+| **template** | Login\_Prompt: Matches "Login as:"... |\r
++---------------------------------------+-----------------------------------------+\r
+\r
+ASDC\_ARTIFACTS\r
+~~~~~~~~~~~~~~~\r
+\r
+The ASDC\_ARTIFACTS table contains the model received from the SDC in\r
+YAML format. APP-C reads this model and identifies the order of the\r
+VNFCs and their resilience types.\r
+\r
+ASDC\_ARTIFACTS parameters\r
+^^^^^^^^^^^^^^^^^^^^^^^^^^\r
+\r
++--------------------------------+------------------------+\r
+| **Parameter Name** | **Example Value** |\r
++================================+========================+\r
+| **asdc\_artifacts\_id** | 1 |\r
++--------------------------------+------------------------+\r
+| **service\_uuid** | Service-uuid |\r
++--------------------------------+------------------------+\r
+| **distribution\_id** | Distribution-ID |\r
++--------------------------------+------------------------+\r
+| **service\_name** | Test |\r
++--------------------------------+------------------------+\r
+| **service\_description** | Test |\r
++--------------------------------+------------------------+\r
+| **resource\_uuid** | Resource-uuid |\r
++--------------------------------+------------------------+\r
+| **resource\_instance\_name** | vSCP |\r
++--------------------------------+------------------------+\r
+| **resource\_name** | vSCP |\r
++--------------------------------+------------------------+\r
+| **resource\_version** | 1.0 |\r
++--------------------------------+------------------------+\r
+| **resource\_type** | VF |\r
++--------------------------------+------------------------+\r
+| **artifact\_uuid** | Artifact-uuid |\r
++--------------------------------+------------------------+\r
+| **artifact\_type** | TOPOLOGY |\r
++--------------------------------+------------------------+\r
+| **artifact\_version** | 1 |\r
++--------------------------------+------------------------+\r
+| **artifact\_description** | VNF Dependency Model |\r
++--------------------------------+------------------------+\r
+| **internal\_version** | 0 |\r
++--------------------------------+------------------------+\r
+| **creation\_date** | 2016-11-17 10:10:18 |\r
++--------------------------------+------------------------+\r
+| **artifact\_name** | Scp-template.yml |\r
++--------------------------------+------------------------+\r
+| **artifact\_content** | <Content> |\r
++--------------------------------+------------------------+\r
+\r
+Sequence Generator API\r
+======================\r
+\r
+The Sequence Generator API generates the steps of execution for LCM\r
+operations at minute-level. This API is exposed using the following\r
+two endpoints:\r
+\r
+- DG plug-in\r
+\r
+- REST API\r
+\r
+The Sequence Generator API takes an input file in JSON format and,\r
+based on the parameters defined in the input file, generates an\r
+output file.\r
+\r
+This chapter comprises the following topics:\r
+\r
+- Sample input file\r
+\r
+- Sample output file\r
+\r
+- Supported actions\r
+\r
+ The input file comprises:\r
+\r
+- Request information\r
+\r
+- Inventory information\r
+\r
+All these sections of the input file and the parameters used are\r
+explained in the subsequent sections.\r
+\r
+Sample Input File\r
+-----------------\r
+\r
+::\r
+\r
+ {\r
+ "request-info": {\r
+ "action": "Stop",\r
+ "action-level": "vm",\r
+ "action-identifier": {\r
+ "vnf-id": "abc"\r
+ },\r
+ "payload": " {\"vnf-host-ip-address\": \"10.147.124.163\" }"\r
+ },\r
+ "inventory-info": {\r
+ "vnf-info": {\r
+ "vnf-id" : "abc",\r
+ "vnf-name": "vSCP",\r
+ "vnf-type": "vSCP",\r
+ "vnf-version" : "1.0",\r
+ "vm": [\r
+ {\r
+ "vserver-id" : "be_vserverid1",\r
+ "vnfc":\r
+ {\r
+ "vnfc-type": "BE",\r
+ "vnfc-name": "BE - Name"\r
+ }\r
+ },\r
+ {\r
+ "vserver-id" : "fe_vserverid1",\r
+ "vnfc":\r
+ {\r
+ "vnfc-type": "FE",\r
+ "vnfc-name": "FE - Name"\r
+ }\r
+ },\r
+ {\r
+ "vserver-id" : "smp_vserverid1",\r
+ "vnfc":\r
+ {\r
+ "vnfc-type": "SMP",\r
+ "vnfc-name": "SMP - Name"\r
+ }\r
+ }\r
+ ]\r
+ }\r
+ }\r
+ }\r
+\r
+\r
+Parameters\r
+~~~~~~~~~~\r
+\r
+This section explains the parameters used in the Sequence Generator\r
+API input file.\r
+\r
++-----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------+-----------------+\r
+| **Parameter name** | **Description** | **Possible values** | **Required?** |\r
++=============================+===============================================================================================================================================================================+=======================================+=================+\r
+| **Request Information** |\r
++-----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------+-----------------+\r
+| action | The action to be executed by Sequence Generator API. | Start,Stop | Y |\r
++-----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------+-----------------+\r
+| action-level | Represents the level for the action such as, vm, vnfc. | Vnf,vnfc,vm,vf-module | Y |\r
++-----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------+-----------------+\r
+| action-identifier | A block containing the action arguments. These are used to specify the object upon which Sequence Generator API operates. At least one action-identifier must be specified. | Vnf-id | N |\r
++-----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------+-----------------+\r
+| vnf-id | Identifies the VNF instance to which this action is to be applied. vnf-id uniquely identifies the service-instance. | String | N |\r
++-----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------+-----------------+\r
+| payload | An action-specific open-format field. The payload can be any valid JSON string value. | AICIdentity and vnf-host-ip-address | N |\r
++-----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------+-----------------+\r
+| **Inventory Information** |\r
++-----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------+-----------------+\r
+| vnfInfo | Represents the VNF information to which this action is to be applied. | String | Y |\r
++-----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------+-----------------+\r
+| vnf-id | Identifies the VNF instance to which this action is to be applied. vnf-id uniquely identifies the service-instance. | String | N |\r
++-----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------+-----------------+\r
+| vnf-name | Identifies the VNF instance to which this action is to be applied. | vSCP | N |\r
++-----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------+-----------------+\r
+| vnf-type | Represents the type of the VNF instance. | vSCP | N |\r
++-----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------+-----------------+\r
+| vnf-version | Represents the version of the VNF instance. | Alphanumeric | N |\r
++-----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------+-----------------+\r
+| vm | Represents the VM information to which this action is to be applied. | List of VMs | Y |\r
++-----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------+-----------------+\r
+| vserver-id | Identifies a specific VM instance to which this action is to be applied. | Alpha-numeric unique ID | Y |\r
++-----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------+-----------------+\r
+| vnfc | Represents the VNFC information to which this action is to be applied. | vnfc-type, vnfc-name | N |\r
++-----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------+-----------------+\r
+| vnfc-type | Represents the type of the VNFC instance. | FE,BE,SMP | N |\r
++-----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------+-----------------+\r
+| vnfc-name | Identifies the VNFC instance to which this action is to be applied. | FE-Name, BE-Name, SMP-Name | N |\r
++-----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------+-----------------+\r
+\r
+Sample Output file\r
+------------------\r
+\r
+::\r
+\r
+ [{\r
+ "transactionId": 1,\r
+ "action": "Stop",\r
+ "action-level": "vm",\r
+ "action-identifier": {\r
+ "vserver-id": "be_vserverid1"\r
+ },\r
+ "payload": " {\"vnf-host-ip-address\": \"10.147.124.163\" }",\r
+ "responses": [{\r
+ "response-message": "failure",\r
+ "response-action": {\r
+ "ignore": "true"\r
+ }\r
+ }]\r
+ },\r
+ {\r
+ "transactionId": 2,\r
+ "action": "Stop",\r
+ "action-level": "vm",\r
+ "action-identifier": {\r
+ "vserver-id": "fe_vserverid1"\r
+ },\r
+ "payload": " {\"vnf-host-ip-address\": \"10.147.124.163\" }",\r
+ "responses": [{\r
+ "response-message": "failure",\r
+ "response-action": {\r
+ "ignore": "true"\r
+ }\r
+ }]\r
+ },\r
+ {\r
+ "transactionId": 3,\r
+ "action": "Stop",\r
+ "action-level": "vm",\r
+ "action-identifier": {\r
+ "vserver-id": "smp_vserverid1"\r
+ },\r
+ "payload": " {\"vnf-host-ip-address\": \"10.147.124.163\" }",\r
+ "responses": [{\r
+ "response-message": "failure",\r
+ "response-action": {\r
+ "ignore": "true"\r
+ }\r
+ }]\r
+ }\r
+ ]\r
+\r
+\r
+Supported Actions\r
+-----------------\r
+\r
+The following actions are supported for the Sequence Generator API\r
+for this release:\r
+\r
+- Generate Runtime Sequence Flow for Start Action with no dependency\r
+ model\r
+\r
+- Generate Runtime Sequence Flow for Stop Action with no dependency\r
+ model\r
+\r
+.. |image0| image:: media/AppCDeployment.png\r
+ :width: 6.50000in\r
+ :height: 2.55903in\r
+.. |image1| image:: media/AppCApidoxExplorer.png\r
+ :width: 6.50000in\r
+ :height: 4.83611in\r
+.. |image2| image:: media/AppCApidoxExplorer2.png\r
+ :width: 6.50000in\r
+ :height: 5.50139in\r
+.. |image3| image:: media/AppCApidoxExplorer3.png\r
+ :width: 6.50000in\r
+ :height: 5.65347in\r
+.. |image4| image:: media/AppCApidoxExplorer4.png\r
+ :width: 6.50000in\r
+ :height: 6.62292in\r
+.. |image5| image:: media/AppCArchitectureDiagram.png\r
+ :width: 6.50000in\r
+ :height: 3.40347in\r
+.. |image6| image:: media/AppCDGOrchestratorArchitecture.png\r
+ :width: 6.36597in\r
+ :height: 3.72903in\r
Code Review / appc.git / commitdiff
