docs/APPC-User-Guide/APPC-User-Guide.rst

   1 .. ============LICENSE_START==========================================\r
   2 .. ===================================================================\r
   3 .. Copyright © 2017 AT&T Intellectual Property. All rights reserved.\r
   4 .. ===================================================================\r
   5 .. Licensed under the Creative Commons License, Attribution 4.0 Intl.  (the "License");\r
   6 .. you may not use this documentation except in compliance with the License.\r
   7 .. You may obtain a copy of the License at\r
   8 .. \r
   9 ..  https://creativecommons.org/licenses/by/4.0/\r
  10 .. \r
  11 .. Unless required by applicable law or agreed to in writing, software\r
  12 .. distributed under the License is distributed on an "AS IS" BASIS,\r
  13 .. WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.\r
  14 .. See the License for the specific language governing permissions and\r
  15 .. limitations under the License.\r
  16 .. ============LICENSE_END============================================\r
  17 .. ECOMP is a trademark and service mark of AT&T Intellectual Property.\r
  18 \r
  19 ===============\r
  20 APPC User Guide\r
  21 ===============\r
  22 \r
  23 APPC Overview and Architecture\r
  24 ==============================\r
  25 The Application Controller (APPC) is one of the components of the ONAP\r
  26 platform. It is responsible for handling the Life Cycle Management (LCM)\r
  27 of Virtual Network Functions (VNFs).\r
  28 \r
  29 This document provides an overview of the APPC components that enable\r
  30 the LCM operations.\r
  31 \r
  32 Implementation\r
  33 --------------\r
  34 The APPC infrastructure is implemented on virtual machines in an\r
  35 OpenStack cloud in the Amsterdam release. APPC is created on top of the OpenDaylight (ODL)\r
  36 platform\r
  37 \r
  38 The following diagram represents a non-redundant APP-C deployment.\r
  39 \r
  40 |image0|\r
  41 \r
  42 Features\r
  43 --------\r
  44 The APPC HTTP API supports Life Cycle Management (LCM) commands,\r
  45 allowing users to manage virtual applications and their components via\r
  46 other ONAP components. Refer to Architecture section for further\r
  47 details.\r
  48 \r
  49 Interface\r
  50 ---------\r
  51 The Application Controller Dashboard interacts with the controller\r
  52 using REST APIs and performs actions on VNF/VNFC/VMs, such as snapshot,\r
  53 lock, sync, and health-check.\r
  54 \r
  55 Dashboard\r
  56 ~~~~~~~~~\r
  57 \r
  58 To open the Application Controller dashboard, go to:\r
  59 \r
  60 |image1|\r
  61 \r
  62 Navigate to the available LCM commands by clicking on\r
  63     **appc-provider-lcm**:\r
  64 \r
  65 |image2|\r
  66 \r
  67 Click on the URI of the desired action to open a frame with information\r
  68 about the action and an option to try it out. For example, to send the\r
  69 action, add the request body as the input parameter value, and click\r
  70 **Try it out!**\r
  71 \r
  72 The following figure shows an example body of a LCM restart request:\r
  73 \r
  74 |image3|\r
  75 \r
  76 If the request is accepted, you should see the following response:\r
  77 \r
  78 |image4|\r
  79 \r
  80 APPC Architecture \r
  81 -----------------\r
  82 \r
  83 This section discusses the APPC internal components in detail.\r
  84 \r
  85 **APPC High Level Architecture**\r
  86 \r
  87 |image5|\r
  88 \r
  89 Northbound REST Layer\r
  90 ~~~~~~~~~~~~~~~~~~~~~\r
  91 \r
  92 This layer is responsible for interfacing with APPC clients, such as SO\r
  93 or SDC and others, exposing YANG-based API via REST HTTP and/or DMaaP\r
  94 messaging (see the Interfaces Summary section for details). In addition,\r
  95 it exposes APPC OAM (Operation Administration Management) APIs, enabling\r
  96 ONAP Operations Manager (OOM) or TechOps portal to perform APPC\r
  97 lifecycle operations\r
  98 \r
  99 APPC Provider\r
 100 ~~~~~~~~~~~~~\r
 101 \r
 102 The APPC Provider module exposes the endpoints for each action\r
 103 supported by APPC. This module uses the YANG model to define the\r
 104 YANG Remote Processing Call (RPC) and data model, in other words,\r
 105 the input and output parameters for each action. The Provider module \r
 106 is responsible for validating the RPC input and for rejecting any\r
 107 malformed input. After successful validation, the APPC Provider\r
 108 calls the Dispatcher to continue the request processing.\r
 109 \r
 110 LCM API\r
 111 ~~~~~~~\r
 112 \r
 113 The APPC exposes an HTTP API to support the Life Cycle Management\r
 114 (LCM) commands sent from ONAP components such as SO, SDC, and the\r
 115 Portal. These commands enable the components to request APPC to\r
 116 perform actions such as to control, modify, start, or stop virtual\r
 117 applications and/or their components. \r
 118 \r
 119 A virtual application is composed of the following layers. A Life\r
 120 Cycle Management command may affect any number of these layers.\r
 121 \r
 122 -  Virtual Network Function (VNF)\r
 123 \r
 124 -  Virtual Network Function Component (VNFC)\r
 125 \r
 126 -  Virtual Machine (VM)\r
 127 \r
 128 APP-C supports two types of LCM requests, as described below.\r
 129 \r
 130 **Note:** For further information about LCM API, including details of\r
 131 all the commands currently supported in APP-C and examples of the\r
 132 request and response format see the ONAP Application Controller (APPC) API Guide. \r
 133 \r
 134 LCM over REST \r
 135 ^^^^^^^^^^^^^^\r
 136 \r
 137 LCM command requests over REST are sent to the APPC using an HTTP\r
 138 POST request. APPC returns one or more responses for each LCM\r
 139 request. \r
 140 \r
 141 The APP-C LCM API provides a POST HTTP API endpoint per command. \r
 142 \r
 143 An **asynchronous** command, containing an authorized and valid\r
 144 request, results in at least two discrete response events:\r
 145 \r
 146 -  an ACCEPT (a synchronous HTTP response) to indicate that the request\r
 147        is accepted and will be processed, and\r
 148 \r
 149 -  a final asynchronous response for the command containing an execution\r
 150        status is sent via DMaaP\r
 151 \r
 152 An unauthorized or invalid request would result in a single\r
 153 ERROR response. \r
 154 \r
 155 For commands such as Restart, Start, and Stop, the asynchronous response\r
 156 is sent over DMaaP.\r
 157 \r
 158 A **synchronous** command, for example Lock or Unlock, results in a\r
 159 single response, which is either SUCCESS or ERROR. For this type of\r
 160 request, the first response is a synchronous HTTP response..\r
 161 \r
 162 For the ONAP Amsterdam release, APPC supports the HTTPS protocol, whereas the plain\r
 163 HTTP requests are blocked..\r
 164 \r
 165 Endpoint format: \r
 166 \r
 167 ``<http-protocol>://<appc-ip>:<appc-api-port>/restconf/operations/appc-provider-lcm:<command-name>``\r
 168 \r
 169 LCM over Message Bus (DMaaP)\r
 170 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^\r
 171 \r
 172 APPC is capable of receiving LCM command requests as messages on the\r
 173 DMaaP bus. In this case, APPC returns one or more responses for each LCM\r
 174 request, similar to LCM over REST, while both are communicated over\r
 175 DMaaP.\r
 176 \r
 177 Configure the Read/Write topics for the DMaaP as described in APPC\r
 178 Deployment, APPC Available Properties.\r
 179 \r
 180 APPC client library, embedded into APPC client’s (for example, SO) code,\r
 181 intends to simplify communication over DMaaP by eliminating topic\r
 182 provisioning at the client site. Refer to\r
 183 http://onap.readthedocs.io/en/latest/ for more details on the APPC\r
 184 Client Library.\r
 185 \r
 186 For further information about the request and response format, see\r
 187 the APPC API Guide at http://onap.readthedocs.io/en/latest/\r
 188 \r
 189 Dispatcher\r
 190 ~~~~~~~~~~\r
 191 \r
 192 The APPC Dispatcher component processes requests received by the Request\r
 193 Handler from other ECOMP components. The Dispatcher checks the\r
 194 conditions are sufficient for performing the request and selects the\r
 195 correct Direct Graph (DG) workflow for execution or rejects the request.\r
 196 When the DG execution is complete, the Dispatching function is\r
 197 responsible for notifying the initiator of the operation with the\r
 198 request execution result (Success/Error) and updates the VNF\r
 199 Orchestration state in Active and Available Inventory (A&AI).\r
 200 \r
 201 The detailed responsibilities of the Dispatcher are as follows:\r
 202 \r
 203 -  Upon receiving the operation request, the Dispatcher performs the\r
 204    synchronous part of the execution:\r
 205 \r
 206    -  Starts the operation's time-to-live countdown\r
 207 \r
 208    -  Queries A&AI to get the VNF type and its current orchestration\r
 209       state\r
 210 \r
 211    -  Checks VNF\_type-specific rules in the LCM State machine for\r
 212       whether to allow or reject the requested command execution\r
 213 \r
 214    -  Allocates and initiates an appropriate DG workflow by invoking the\r
 215       Service Logic Interpreter (SLI) framework to start the\r
 216       asynchronous part of the execution\r
 217 \r
 218    -  Returns a response to the initiator: OK or reject (for example, if\r
 219       the State Machine blocks the operation, no DG or time-to-live, or\r
 220       bad parameters)\r
 221 \r
 222    -  If the operation is rejected, the Dispatcher generates an\r
 223       appropriate Audit log for the Event and Error Logging Framework\r
 224       (EELF) and the Local Event Journal\r
 225 \r
 226 -  Upon workflow completion, the Dispatcher:\r
 227 \r
 228    -  Receives the execution results from the DG from the SLI framework\r
 229 \r
 230    -  Publishes the execution result over DMaaP (success or error)\r
 231 \r
 232    -  Updates VNF status in A&AI\r
 233 \r
 234    -  Generates an Audit log for EELF and Local Event Journal\r
 235 \r
 236 Request Handler\r
 237 ^^^^^^^^^^^^^^^\r
 238 \r
 239 The Request Handler manages incoming requests and locks APPC for new\r
 240 requests, as needed for operations with a specific command execution\r
 241 sequences.\r
 242 \r
 243 Lifecycle Management\r
 244 ^^^^^^^^^^^^^^^^^^^^\r
 245 \r
 246 The Lifecycle Management VNF State Machine enables the Dispatching\r
 247 function to determine the validity of the requested operation (desired\r
 248 state) as a function of the current VNF state, acquired from the A&AI.\r
 249 The State Machine maintains its data (states and valid operations)\r
 250 in-memory. At the point of APPC initialization, the State Machine\r
 251 constructs a matrix based on the metadata of the current operation and\r
 252 the valid desired state. \r
 253 \r
 254 Command Executor\r
 255 ^^^^^^^^^^^^^^^^\r
 256 \r
 257 Manages command execution queue.\r
 258 \r
 259 State Machine\r
 260 ~~~~~~~~~~~~~\r
 261 \r
 262 The VNF State machine enables the Dispatching function to determine\r
 263 the validity of the requested operation (desired state) as a\r
 264 function of the current VNF state, acquired from the A&AI. The State\r
 265 machine maintains its data (states and valid operations) in-memory.\r
 266 At the point of APP-C initialization, the State Machine constructs a\r
 267 matrix based on the metadata of the current operation and the valid\r
 268 desired state. \r
 269 \r
 270 The Service Logic Interpreter (SLI) Framework\r
 271 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\r
 272 \r
 273 The SLI framework is responsible for executing Directed Graphs (DGs).\r
 274 The Dispatcher invokes the SLI framework to execute a specific DG, based\r
 275 on the input action. The SLI executes the DG and the sub-DG and returns\r
 276 a success or failure response to the caller along with the context\r
 277 variables used to exchange data with the calling body (for example, the\r
 278 Dispatcher). The caller can use the SLI context to specify data required\r
 279 for DG execution. The DG returns the same context when execution\r
 280 completes.\r
 281 \r
 282 Currently, there is a combination of input action specific and/or VNF\r
 283 type specific DG’s as well as a DGOrchestrator DG which is action and\r
 284 VNF type agnostic. The DGOrchestrator approach consists of the\r
 285 following:\r
 286 \r
 287 -  DGOrchestrator DG which:\r
 288 \r
 289    -  Accepts request from the Dispatcher and converts it into DG\r
 290       context format\r
 291 \r
 292    -  Calls A&AI to retrieve the inventory for the VNF instance\r
 293 \r
 294    -  Calls a Sequence Generator for start/stop actions which generates\r
 295       a workflow sequence containing a set of start or stop VM requests\r
 296 \r
 297    -  Auto-generates a workflow for other requests with a single step\r
 298 \r
 299    -  Executes each step in the workflow by invoking DG’s to interact\r
 300       with the VNF, OpenStack, or Ansible/Chef servers. These DG’s which\r
 301       are specific to the protocol and possibly action. Some DG’s may\r
 302       update A&AI (such as for Configure) or retrieve the VNF running\r
 303       configuration.\r
 304 \r
 305    -  Returns success/failure status to the Dispatcher.\r
 306 \r
 307 In the future, all action/VNF type specific DG’s will be migrated to the\r
 308 DGOrchestrator approach.\r
 309 \r
 310 The following diagram shows the Amsterdam Release DGOrchestrator\r
 311 architecture\r
 312 \r
 313     |image6|\r
 314 \r
 315 Westbound Layer\r
 316 ~~~~~~~~~~~~~~~\r
 317 \r
 318 A&AI\r
 319 ^^^^\r
 320 \r
 321     A&AI is an ONAP component, which maintains information about VNF\r
 322     instances. APPC uses A&AI as a source of the true VNF status,\r
 323     topology and operational data. In addition, at the end of each\r
 324     operation, APPC updates the VNF changes that result from the\r
 325     operation: for example, VNFC record(s) are added after\r
 326     configuration. The VNF orchestration status is not updated for\r
 327     read-only operations such as Sync or Audit. In the case of the VNF\r
 328     Terminate operation, APPC removes the terminated VNF from A&AI by\r
 329     deleting its Virtual Machines (VMs). \r
 330 \r
 331     The Dispatching function and operation-specific DGs manage access to\r
 332     the A&AI using the A&AI Adapter.  \r
 333 \r
 334 Southbound Layer\r
 335 ~~~~~~~~~~~~~~~~\r
 336 \r
 337 Southbound VNF Adapters\r
 338 ^^^^^^^^^^^^^^^^^^^^^^^\r
 339 \r
 340     APPC uses several adapters to communicate with VNFs. The Interface\r
 341     as a Service (IAAS) adapter is part of the OpenDayLight (ODL)\r
 342     platform, while other adapters have been added by the ONAP\r
 343     development.\r
 344 \r
 345 Restconf Adapter\r
 346 ^^^^^^^^^^^^^^^^^\r
 347 \r
 348     The Adapter is responsible for configuration tasks, using JSON\r
 349     format, for VNFs supporting Restconf API.\r
 350     \r
 351 **Using the Restconf Adapter**\r
 352      The restconf adapter is normally called from a directed graph.\r
 353      An "execute" node block should be used in the directed graph to\r
 354      the "org.onap.appc.adapter.rest.RestAdapter" plug-in. There are\r
 355      several methods available to use:\r
 356 \r
 357 - commonGet\r
 358 - commonDelete\r
 359 - commonPost\r
 360 - commonPut\r
 361      \r
 362 There are several parameters that the RestAdapter plug-in takes\r
 363 \r
 364 org.onap.appc.instance.URI\r
 365   The url that the rest request will be made to\r
 366 org.onap.appc.instance.requestBody\r
 367   The body of the rest request\r
 368 org.onap.appc.instance.headers\r
 369   The header of the rest request\r
 370 org.onap.appc.instance.haveHeader\r
 371   true/false value which specifies if a header is present.\r
 372   (Should be set to "true" if the org.onap.appc.instance.headers\r
 373   parameter is defined, or set to "false" if the\r
 374   headers parameter is not defined)\r
 375   \r
 376 There are several parameters returned back to the DG from the RestAdapter\r
 377 \r
 378 org.onap.rest.result.code\r
 379   An http code representing if the request completed. Will always be 200\r
 380   if the request completes. See the below parameter for the exact http code\r
 381   that gets returned.\r
 382 org.onap.rest.agent.result.code\r
 383   The http code returned from the rest request.\r
 384 org.onap.rest.agent.result.message\r
 385   The status or body returned from the rest request.\r
 386   \r
 387 An example execute node:\r
 388 \r
 389 ::\r
 390 \r
 391 <execute plugin='org.onap.appc.adapter.rest.RestAdapter' method='commonPut' >\r
 392 <parameter name='org.onap.appc.instance.URI' value='`$restUrl`'/>\r
 393 <parameter name='org.onap.appc.instance.requestBody' value='`$jsonContent`'/>\r
 394 <parameter name='org.onap.appc.instance.headers' value='{"Content-type":"application/json"}'/>\r
 395 <parameter name='org.onap.appc.instance.haveHeader' value='true'/>\r
 396     \r
 397     \r
 398 \r
 399 Netconf Adapter\r
 400 ^^^^^^^^^^^^^^^\r
 401 \r
 402     The Adapter is responsible for configuration tasks, using XML\r
 403     format, for VNFs supporting Netconf API.\r
 404 \r
 405 IAAS Adapter \r
 406 ^^^^^^^^^^^^^\r
 407 \r
 408     The IAAS Adapter connects APPC with the OpenStack controllers to\r
 409     perform various operations on VMs and VNFs such as Restart, Migrate,\r
 410     and Rebuild. The IAAS Adapter integrates as a DG plugin, while the\r
 411     DGs call the services exposed by the adapter.\r
 412 \r
 413 SSH (XML/CLI) Adapter\r
 414 ^^^^^^^^^^^^^^^^^^^^^\r
 415 \r
 416     A custom adapter that enables connection to a VNF using an SSH\r
 417     session. It is designed to support CLI and XML protocols, including\r
 418     Netconf. It is used to load configurations and retrieve the running\r
 419     configuration.\r
 420 \r
 421 Chef Adaptor\r
 422 ^^^^^^^^^^^^\r
 423 \r
 424     This adaptor incorporates a client for an external Chef server,\r
 425     which connects to VNF NB APIs. The adaptor enables APPC to operate\r
 426     cookbooks (Chef recipes) to perform various LCM operations over\r
 427     VNFs, connected to the Chef server.\r
 428 \r
 429 Ansible Adapter\r
 430 ^^^^^^^^^^^^^^^\r
 431 \r
 432     This adaptor incorporates a client for an external Ansible server,\r
 433     which connects to VNF NB APIs. The adaptor enables APPC to operate\r
 434     playbooks to perform various LCM operations over VNFs connected to\r
 435     the Ansible server.\r
 436 \r
 437 Cross Cutting Components\r
 438 ~~~~~~~~~~~~~~~~~~~~~~~~\r
 439 \r
 440 The Cross Cutting Component services operate across all APPC modules.\r
 441 \r
 442 Configuration\r
 443 ^^^^^^^^^^^^^\r
 444 \r
 445 Used to configure operational parameters of APPC modules based on\r
 446 function-specific configuration files, for example:\r
 447 \r
 448 -  ``log4j.properties`` for the logging service\r
 449 \r
 450 -  ``appc.properties`` for core APPC-related configuration\r
 451 \r
 452 -  ``dblib.properties`` for managing APPC database-related configuration\r
 453 \r
 454 -  ``aaiclient.properties`` for managing A&AI-related configuration\r
 455 \r
 456 KPI Service\r
 457 ^^^^^^^^^^^\r
 458 \r
 459 This Cross Cutting component manages KPI measurement, storage and\r
 460 reporting.\r
 461 \r
 462 Enable matrix logs to log the number of hits of the configured method of\r
 463 APPC, by configuring the following properties in ``appc.properties:``::\r
 464 \r
 465    metric.enabled=<true>\r
 466    schedule.policy.metric.start.time=<time value in hhmmss>\r
 467    schedule.policy.metric.period = 60(interval in seconds)\r
 468 \r
 469 Security Service\r
 470 ^^^^^^^^^^^^^^^^\r
 471 \r
 472 This component implements AAF (Authentication and Authorization\r
 473 Framework) for APPC API security. The user provides a user name and\r
 474 password in the request that will be validated against centralize AAF.\r
 475 [Note: For Amsterdam Releasse, AAF is not used]\r
 476 \r
 477 Logging Service\r
 478 ^^^^^^^^^^^^^^^\r
 479 \r
 480 Implements EELF (Event and Error Logging Framework) to manage and\r
 481 generate logs (refer to Logging section).\r
 482 \r
 483 Data Access Service\r
 484 ^^^^^^^^^^^^^^^^^^^\r
 485 \r
 486 Provides access to the internal data store.\r
 487 \r
 488 Transactions store\r
 489 ~~~~~~~~~~~~~~~~~~\r
 490 \r
 491 For each operation request procedure that completes or terminates,\r
 492 APPC generates and stores an accurate transaction record in its\r
 493 internal database, including:\r
 494 \r
 495 -  Timestamp\r
 496 \r
 497 -  Request ID\r
 498 \r
 499 -  Start time\r
 500 \r
 501 -  End time\r
 502 \r
 503 -  VF\_ID\r
 504 \r
 505 -  VF\_type\r
 506 \r
 507 -  Sub-component (optional) e.g. VFC\_ID/VM UUID\r
 508 \r
 509 -  Operation: for example Start, Configure, etc.\r
 510 \r
 511 -  Result: Success/Error code and description, as published to the\r
 512    initiator\r
 513 \r
 514 Interfaces Summary\r
 515 ~~~~~~~~~~~~~~~~~~\r
 516 \r
 517 +-------------------+------------+-------------------------+-------------------+-------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+\r
 518 | **Source**        | **Flow**   | **Destination**         | **Service**       | **Port**    | **Purpose / Comments**                                                                                                                                                     |\r
 519 +===================+============+=========================+===================+=============+============================================================================================================================================================================+\r
 520 | APPC              |    ->      | A&AI                    | REST              | 8443        | APPC retrieves and updates the VNF data in AAI.                                                                                                                            |\r
 521 +-------------------+------------+-------------------------+-------------------+-------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+\r
 522 | APPC              |    ->      | SLI                     | Java (internal)   | N/A         | APPC sends the LCM API request to SLI for DG execution                                                                                                                     |\r
 523 +-------------------+------------+-------------------------+-------------------+-------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+\r
 524 | APPC              |    ->      | South-bound Adapters    | Java (internal)   | N/A         | APPC interacts  with southbound adapters for VNF Lifecycle Management Actions                                                                                              |\r
 525 +-------------------+------------+-------------------------+-------------------+-------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+\r
 526 | APPC              |    ->      | NETCONF                 | NETCONF           | 830 or 22   | NETCONF Adapter communicates on port 830 (default) or port 22 (SSH – if set up)                                                                                            |\r
 527 +-------------------+------------+-------------------------+-------------------+-------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+\r
 528 | APPC              |    ->      | Chef Server             | HTTP/HTTPS        | 80/443      | Chef adapter communicate on port 80 (HTTP) or port 443 (HTTPS)                                                                                                             |\r
 529 +-------------------+------------+-------------------------+-------------------+-------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+\r
 530 | APPC              |    ->      | Ansible Server          | HTTP              | 8000        | Port 8000 is used for communication between the APPC Ansible Adaptor and the Ansible Server.                                                                               |\r
 531 +-------------------+------------+-------------------------+-------------------+-------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+\r
 532 | APPC              |    ->      | MySQL                   | Java (internal)   | 3306        |                                                                                                                                                                            |\r
 533 +-------------------+------------+-------------------------+-------------------+-------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+\r
 534 | APPC              |    ->      | DG Builder              | Java (internal)   | 3000        |                                                                                                                                                                            |\r
 535 +-------------------+------------+-------------------------+-------------------+-------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+\r
 536 | APPC              |    ->      | MD-SAL, Apidoc, Karaf   | Java (internal)   | 8282        |                                                                                                                                                                            |\r
 537 +-------------------+------------+-------------------------+-------------------+-------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+\r
 538 | APPC              |    ->      | DMaaP                   | JMS               | 3904        | APPC sends the Asynchronous responses and Failure events to DMaaP Message Bus                                                                                              |\r
 539 +-------------------+------------+-------------------------+-------------------+-------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+\r
 540 | 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
 541 +-------------------+------------+-------------------------+-------------------+-------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+\r
 542 | SDC               |    ->      | APPC                    | DMaaP             | 3904        | APPC requests and receives notifications from SDC for VNF License Artifacts and TOSCA dependency models.                                                                   |\r
 543 +-------------------+------------+-------------------------+-------------------+-------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+\r
 544 | 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
 545 +-------------------+------------+-------------------------+-------------------+-------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+\r
 546 | OOM               |    ->      | APPC                    | DMaaP             | 3904        | APPC receives operational commands: Start, Graceful Stop.                                                                                                                  |\r
 547 |                   |            |                         |                   |             | APPC reports: status, KPIs.                                                                                                                                                |\r
 548 +-------------------+------------+-------------------------+-------------------+-------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+\r
 549 \r
 550 APPC Deployment \r
 551 ================\r
 552 \r
 553 Refer to the APPC Deployment documentation at\r
 554 http://onap.readthedocs.io/en/latest/submodules/appc/deployment.git/docs/index.html\r
 555 \r
 556 Application Controller VNF Onboarding\r
 557 =====================================\r
 558 \r
 559 LCM Command Execution Overview\r
 560 ------------------------------\r
 561 \r
 562 The Application Controller assumes that the A&AI instance it is\r
 563 configured with contains all the information it needs about\r
 564 VNF/VNFC/VMs, otherwise any request by the user to perform an action\r
 565 on a VNF will fail. The Application Controller uses a variety of SQL\r
 566 tables in order to perform actions on a VNF, all of which are\r
 567 described in Creation of DGs\r
 568 \r
 569 DGs are created using the Direct Graph Builder - Node Red graphical\r
 570 utility for DGs creation. DGs are then stored as XML files and loaded to\r
 571 APPC MySQL database. The DGs invoke the execution of Java code from\r
 572 different nodes.\r
 573 \r
 574 DGs are resolved according to LCM Action, API version, VNF Type, and VNF\r
 575 Version.\r
 576 \r
 577 The SLI framework is responsible for executing the DGs.\r
 578 \r
 579 Data Setup. \r
 580 ~~~~~~~~~~~~\r
 581 \r
 582 Initially, Application Controller should have a set of DGs designed\r
 583 for the specific VNF type. These DGs are stored in the SVC\_LOGIC\r
 584 table.\r
 585 \r
 586 After a user sends an action request to the controller, the\r
 587 Application Controller uses the VNF\_DG\_MAPPING table to map the\r
 588 requested action to a specific DG. If the mapping was successful,\r
 589 the input body is validated and the user receives a synchronous\r
 590 response containing an Accept or a Reject message to indicate\r
 591 whether the request was rejected or whether it was accepted and the\r
 592 controller initiated the DG flow.\r
 593 \r
 594 During the execution of a DG, the controller may use one or more SQL\r
 595 tables to fetch or store data. For example, in order to perform a\r
 596 ConfigModify action, the controller needs to fetch a username and\r
 597 password to connect to the VNF and change its configuration.\r
 598 \r
 599 ALL tables used during DG execution are described below.\r
 600 \r
 601 Request execution\r
 602 -----------------\r
 603 \r
 604 Following initial request validation, APPC queries the A&AI inventory to\r
 605 acquire all the required information regarding topology of VNF/VNFC/VMs,\r
 606 operational status and operational data of the requested VNF instance. A\r
 607 missing target VF instance or any missing mandatory parameter in A&AI\r
 608 generate a rejection.\r
 609 \r
 610 After acquiring the VNF type from A&AI, APPC uses the VNF\_DG\_MAPPING\r
 611 table to map the requested action to a specific DG. No such DG located\r
 612 in the table generates a Reject response to the user.\r
 613 \r
 614 The Dispatcher state machine applies operation policies. A policy\r
 615 allowing execution generates an Accept response to the user. Not\r
 616 allowing execution generates a Reject response.\r
 617 \r
 618 If the first two steps were successful, the controller initiates the\r
 619 appropriate DG.\r
 620 \r
 621 During the execution of a DG, the controller may use one or more SQL\r
 622 tables to fetch or store data. For example, to perform a ConfigModify\r
 623 action, the controller needs to fetch a username and password to connect\r
 624 to the VNF and change its configuration.\r
 625 \r
 626 `Data Setup <#_Data_Setup>`__ describes the tables used during DG\r
 627 execution.\r
 628 \r
 629 If APPC is forced stopped while it is executing an LCM request, it might\r
 630 take some time to terminate all the threads that are being executed. In\r
 631 addition, the old threads might start to execute again once the APPC is\r
 632 restarted. The time when these treads start to execute again even after\r
 633 an APPC restart is dependent on the LCM request executed by the threads\r
 634 in the LCM queue and the ThreadPool size. To avoid this, it is\r
 635 recommended that:\r
 636 \r
 637 -  Start APPC only after a while to ensure that the interrupted threads\r
 638    are not executed again.\r
 639 \r
 640 -  Do not execute the OAM-Forceful Stop command if the system is\r
 641    executing an LCM request. Let the system operate in Maintenance mode.\r
 642 \r
 643    1. .. rubric:: Creation of DGs\r
 644          :name: creation-of-dgs\r
 645 \r
 646 DGs are created using the Direct Graph Builder - Node Red graphical\r
 647 utility for DGs creation. DGs are then stored as XML files and loaded to\r
 648 APPC MySQL database. The DGs invoke the execution of Java code from\r
 649 different nodes.\r
 650 \r
 651 At runtime, DGs are resolved according to LCM Action, API version, VNF\r
 652 Type, and VNF Version.\r
 653 \r
 654 The SLI framework is responsible for executing the DGs.\r
 655 \r
 656 Data Setup\r
 657 ----------\r
 658 \r
 659 APPC uses MySQL database as a persistent store. This section describes\r
 660 the tables in general and the tables that require data to be set up\r
 661 before sending a request.\r
 662 \r
 663 SVC\_LOGIC Table\r
 664 ~~~~~~~~~~~~~~~~\r
 665 \r
 666 SVC\_LOGIC table stores all NodeRed DGs invoked by actions executed by\r
 667 APPC. The SLI framework uses this table for running the DG. If the DG\r
 668 does not exist in this table, the SLI framework returns a 'DG not found'\r
 669 error.\r
 670 \r
 671 SVC\_LOGIC Parameters\r
 672 ^^^^^^^^^^^^^^^^^^^^^\r
 673 \r
 674 +----------------------+----------------------+\r
 675 | **Parameter Name**   | **Example Values**   |\r
 676 +======================+======================+\r
 677 | **module**           | APPC                 |\r
 678 +----------------------+----------------------+\r
 679 | **rpc**              | Generic\_Audit       |\r
 680 +----------------------+----------------------+\r
 681 | **version**          | 2.0.0                |\r
 682 +----------------------+----------------------+\r
 683 | **mode**             | sync                 |\r
 684 +----------------------+----------------------+\r
 685 | **active**           | N                    |\r
 686 +----------------------+----------------------+\r
 687 | **graph**            | <BLOB>               |\r
 688 +----------------------+----------------------+\r
 689 \r
 690 **module, rpc, version**\r
 691 \r
 692 The ``module``, ``rpc``, and ``version`` parameters uniquely identify a Directed\r
 693 Graph (DG). The SLI framework uses these three parameters to invoke a DG\r
 694 or sub-DG. By convention, for the main DG, rpc is a combination of 'VNF\r
 695 type' (the generic type applied to all VNFs) followed by '\_' and\r
 696 'action'. This is the default convention; resolution of the DG for\r
 697 specific actions is handled individually in the relevant forthcoming\r
 698 sections.\r
 699 \r
 700 **mode**\r
 701 \r
 702 The DG execution node. This value is set to ‘sync’ for all APPC DGs.\r
 703 \r
 704 **active**\r
 705 \r
 706 This flag is the value of either 'Y' or 'N'. This flag is only used if\r
 707 specific version of DG is not mentioned while calling DG. If version of\r
 708 DG is not mentioned SLI framework will look for DG with active Flag set\r
 709 to 'Y' and execute it if found.\r
 710 \r
 711 **graph**\r
 712 \r
 713 This is actual graph invoked by SLI framework. The data type is SQL\r
 714 BLOB.\r
 715 \r
 716 VNF\_DG\_MAPPING\r
 717 ~~~~~~~~~~~~~~~~\r
 718 \r
 719 The VNF\_DG\_MAPPING table stores the VNF and its corresponding DG. This\r
 720 is used by the DG resolver logic of the Dispatcher to map the DG to the\r
 721 requested action. Only the mapping is stored; the actual DG is stored in\r
 722 the SVC\_LOGIC table.\r
 723 \r
 724 The DG resolver logic uses a combination of action, api\_version and\r
 725 vnf\_type to retrieve the DG details: dg\_name (rpc column of SVC\_LOGIC\r
 726 table), dg\_version and dg\_module.\r
 727 \r
 728 The module, rpc and version uniquely identify the DG.\r
 729 \r
 730 The following assigned priority resolves the VNF DG:\r
 731 \r
 732 1. ``action``\r
 733 \r
 734 2. ``api_version``\r
 735 \r
 736 3. ``vnf_type``\r
 737 \r
 738 4. ``vnf_version``\r
 739 \r
 740 Blank, null or ‘\*’ values in ``api_version``, ``vnf_type`` and ``vnf_version``\r
 741 are matched with any values by the DG resolver. For example, a generic\r
 742 DG which can be invoked on any type of VNF ``vnf_type`` can be blank /\r
 743 null or \*. The DG resolver logic first tries to match a specific DG,\r
 744 and if this is not found, then look for a generic match using ‘\*’. For\r
 745 example as illustrated in the Example values in below table, an entry\r
 746 for the Test action and vnf\_type VSBG is specific, so it is only used\r
 747 for VNFs of type VSBG, whereas for the Sync action the same DG is used\r
 748 for any type of VNF and any version.\r
 749 \r
 750 VNF\_DG\_MAPPING Parameters\r
 751 ^^^^^^^^^^^^^^^^^^^^^^^^^^^\r
 752 \r
 753 +----------------------+----------------------+-----------------+\r
 754 | **Parameter Name**   | **Example Values**                     |\r
 755 +======================+======================+=================+\r
 756 | **action**           | Test                 | Sync            |\r
 757 +----------------------+----------------------+-----------------+\r
 758 | **api\_verson**      | 2                    |                 |\r
 759 +----------------------+----------------------+-----------------+\r
 760 | **vnf\_type**        | vSBG                 |                 |\r
 761 +----------------------+----------------------+-----------------+\r
 762 | **vnf\_version**     |                      |                 |\r
 763 +----------------------+----------------------+-----------------+\r
 764 | **dg\_name**         | vSBG\_Test           | Generic\_Sync   |\r
 765 +----------------------+----------------------+-----------------+\r
 766 | **dg\_version**      | 2.0.0.1              | 2.0.0           |\r
 767 +----------------------+----------------------+-----------------+\r
 768 | **dg\_module**       | APPC                 | APPC            |\r
 769 +----------------------+----------------------+-----------------+\r
 770 \r
 771 VNFC\_DG\_MAPPING\r
 772 ~~~~~~~~~~~~~~~~~\r
 773 \r
 774 VNFC\_DG\_MAPPING stores the VNFC and its corresponding DG. The DG\r
 775 resolver logic of the Dispatcher uses this to map the DG to the\r
 776 requested action. Only the mapping is stored; the actual DG is stored in\r
 777 the SVC\_LOGIC table.\r
 778 \r
 779 The DG resolver logic uses a combination of ``action``, ``api_version``,\r
 780 ``vnf_type``, and ``vnfc_type`` to retrieve the DG details: ``dg_name`` (rpc\r
 781 column of SVC\_LOGIC table), ``dg_version``, and ``dg_module``.\r
 782 \r
 783 The module, rpc and version uniquely identify the DG.\r
 784 \r
 785 The following assigned priority resolves the VNF DG:\r
 786 \r
 787 1. ``action``\r
 788 \r
 789 2. ``api_version``\r
 790 \r
 791 3. ``vnf_type``\r
 792 \r
 793 4. ``vnfc_type``\r
 794 \r
 795 The DG resolver matches blank, null or ‘\*’ values in ``api_version`` ,\r
 796 ``vnf_type`` and ``vnfc_type`` with any values. For example, a generic DG\r
 797 which can be invoked on any type of VNFC 'vnfc\_type' can be blank /\r
 798 null or \*. The DG resolver logic first tries to match a specific DG. If\r
 799 this is not found, the DG resolver looks for a generic match using ‘\*’.\r
 800 \r
 801 VNFC\_DG\_MAPPING parameters\r
 802 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^\r
 803 \r
 804 +----------------------+---------------------+\r
 805 | **Parameter Name**   | **Example Value**   |\r
 806 +======================+=====================+\r
 807 | **action**           |                     |\r
 808 +----------------------+---------------------+\r
 809 | **api\_version**     |                     |\r
 810 +----------------------+---------------------+\r
 811 | **vnf\_type**        |                     |\r
 812 +----------------------+---------------------+\r
 813 | **vnfc\_type**       |                     |\r
 814 +----------------------+---------------------+\r
 815 | **dg\_name**         |                     |\r
 816 +----------------------+---------------------+\r
 817 | **dg\_version**      |                     |\r
 818 +----------------------+---------------------+\r
 819 | **dg\_module**       |                     |\r
 820 +----------------------+---------------------+\r
 821 \r
 822 DEVICE\_AUTHENTICATION\r
 823 ~~~~~~~~~~~~~~~~~~~~~~\r
 824 \r
 825 The DEVICE\_AUTHENTICATION table stores device authentication\r
 826 details. It is used by actions such as Audit and Sync which connect\r
 827 with VNFs. This table stores a record that corresponds to each VNF\r
 828 type, so ``vnf_type`` is unique.\r
 829 \r
 830 Username, password and port\_number are fields corresponding to\r
 831 ``vnf_type``.\r
 832 \r
 833 DEVICE\_AUTHENTICATION Parameters\r
 834 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\r
 835 \r
 836 +----------------------------------+---------------------+\r
 837 | **Parameter Name**               | **Example Value**   |\r
 838 +==================================+=====================+\r
 839 | **device\_authentication\_id**   | 41                  |\r
 840 +----------------------------------+---------------------+\r
 841 | **vnf\_type**                    | vDBE-V              |\r
 842 +----------------------------------+---------------------+\r
 843 | **user\_name**                   | root                |\r
 844 +----------------------------------+---------------------+\r
 845 | **password**                     | <password>          |\r
 846 +----------------------------------+---------------------+\r
 847 | **port\_number**                 | 22                  |\r
 848 +----------------------------------+---------------------+\r
 849 \r
 850 VNF\_LOCK\_MANAGEMENT\r
 851 ~~~~~~~~~~~~~~~~~~~~~\r
 852 \r
 853 The VNF\_LOCK\_MANAGEMENT table is used to persist data for vnf\r
 854 locking. APPC locks the vnf id when actions start executing on that\r
 855 vnf id. This table stores vnf\_id i.e. resource\_id  along with\r
 856 owner , expiration\_time or timeout. Before execution of request,\r
 857 the dispatcher checks if VNF\_ID is already locked by another action\r
 858 in execution. If VNF\_ID is not locked, the dispatcher will locks it\r
 859 or else returns a VNF locked error to caller.\r
 860 \r
 861 VNF\_LOCK\_MANAGEMENT Parameters\r
 862 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\r
 863 \r
 864 +----------------------+---------------------+\r
 865 | **Parameter Name**   | **Example Value**   |\r
 866 +======================+=====================+\r
 867 | **resource\_id**     | AUDIT\_1652         |\r
 868 +----------------------+---------------------+\r
 869 | **owner\_id**        | vDBE-V              |\r
 870 +----------------------+---------------------+\r
 871 | **updated**          | 1474457140000       |\r
 872 +----------------------+---------------------+\r
 873 | **timeout**          | 0                   |\r
 874 +----------------------+---------------------+\r
 875 | **ver**              | 22                  |\r
 876 +----------------------+---------------------+\r
 877 \r
 878 This table do not require any initial setup.\r
 879 \r
 880 VNF\_STATE\_MANAGEMENT\r
 881 ~~~~~~~~~~~~~~~~~~~~~~\r
 882 \r
 883 The VNF\_STATE\_MANAGEMENT table is used to store the operational state\r
 884 of VNF\_ID, whether it is stable or unstable. It stores state, owner and\r
 885 updated time (in milliseconds). This table does not require any initial\r
 886 setup.\r
 887 \r
 888 VNF\_STATE\_MANAGEMENT Parameters\r
 889 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\r
 890 \r
 891 +----------------------+-------------------------------------+\r
 892 | **Parameter Name**   | **Example Value**                   |\r
 893 +======================+=====================================+\r
 894 | **vnf\_if**          | ASHISH\_VSBG\_VNFS\_1787            |\r
 895 +----------------------+-------------------------------------+\r
 896 | **state**            | STABLE                              |\r
 897 +----------------------+-------------------------------------+\r
 898 | **owner\_id**        | ORIG\_1787@REQ\_1787@SUBREQ\_1787   |\r
 899 +----------------------+-------------------------------------+\r
 900 | **updated**          | 1474457140000                       |\r
 901 +----------------------+-------------------------------------+\r
 902 | **timeout**          | 0                                   |\r
 903 +----------------------+-------------------------------------+\r
 904 | **ver**              | 22                                  |\r
 905 +----------------------+-------------------------------------+\r
 906 \r
 907 UPLOAD\_CONFIG\r
 908 ~~~~~~~~~~~~~~\r
 909 \r
 910 The UPLOAD\_CONFIG table is used by configuration management actions\r
 911 such as Audit, Sync, ConfigModify, Terminate, and similar. It stores\r
 912 device configuration: one row or record corresponds to one VNFC, so\r
 913 therefore a VNF that has multiple VNFCs has multiple rows in the\r
 914 table.\r
 915 \r
 916 The UPLOAD\_CONFIG table stores configuration as the following\r
 917 types:\r
 918 \r
 919 -  ``Current``\r
 920 \r
 921 -  ``Running``\r
 922 \r
 923 -  ``Historic``\r
 924 \r
 925 The ``config_indicator`` column denotes the type of configuration,\r
 926 where a null value denotes ``Historic`` configuration. For a single VNFC\r
 927 there should only be one ``Current`` and one ``Running`` configuration , but\r
 928 there can be multiple Historic configurations. This table does not\r
 929 require any initial setup.\r
 930 \r
 931 UPLOAD\_CONFIG Parameters\r
 932 ^^^^^^^^^^^^^^^^^^^^^^^^^\r
 933 \r
 934 +----------------------------+-------------------------+-------------------------+\r
 935 | **Parameter Name**         | **Example Values**                                |\r
 936 +============================+=========================+=========================+\r
 937 | **upload\_config\_id**     | 63                      | 67                      |\r
 938 +----------------------------+-------------------------+-------------------------+\r
 939 | **request\_id**            | 3                       | REQ\_1690               |\r
 940 +----------------------------+-------------------------+-------------------------+\r
 941 | **originator\_id**         | 12345                   | ORIG\_1690              |\r
 942 +----------------------------+-------------------------+-------------------------+\r
 943 | **service\_description**   | abcde                   | abcde                   |\r
 944 +----------------------------+-------------------------+-------------------------+\r
 945 | **action**                 | ConfigModify            | Sync                    |\r
 946 +----------------------------+-------------------------+-------------------------+\r
 947 | **upload\_date**           | 2016-08-01 14:30:40     | 2016-09-22 12:30:40     |\r
 948 +----------------------------+-------------------------+-------------------------+\r
 949 | **vnf\_id**                | AUDIT\_1767             | AUDIT\_1690             |\r
 950 +----------------------------+-------------------------+-------------------------+\r
 951 | **vnf\_name**              | GET\_RUN\_CONFIG\_VNF   | GET\_RUN\_CONFIG\_VNF   |\r
 952 +----------------------------+-------------------------+-------------------------+\r
 953 | **vm\_name**               | GET\_RUN\_CONFIG\_VNF   | GET\_RUN\_CONFIG\_VNF   |\r
 954 +----------------------------+-------------------------+-------------------------+\r
 955 | **vnf\_type**              | vDBE-V                  | vDBE-V                  |\r
 956 +----------------------------+-------------------------+-------------------------+\r
 957 | **vnfc\_type**             | vDBE-V2                 | vDBE-V1                 |\r
 958 +----------------------------+-------------------------+-------------------------+\r
 959 | **host\_ip\_address**      | 135.25.69.37            |                         |\r
 960 +----------------------------+-------------------------+-------------------------+\r
 961 | **config\_indicator**      | Current                 | Running                 |\r
 962 +----------------------------+-------------------------+-------------------------+\r
 963 | **pending\_delete**        |                         |                         |\r
 964 +----------------------------+-------------------------+-------------------------+\r
 965 | **content**                | Dummy\_current          | <Configuration>         |\r
 966 +----------------------------+-------------------------+-------------------------+\r
 967 \r
 968 DEVICE\_INTERFACE\_PROTOCOL\r
 969 ~~~~~~~~~~~~~~~~~~~~~~~~~~~\r
 970 \r
 971 The DEVICE\_INTERFACE\_PROTOCOL table stores the VNF type and\r
 972 corresponding sub-DG used to get the running configuration of a device.\r
 973 The 'getRunningConfig' DG, which is a sub-DG called by Audit and Sync\r
 974 DG, uses this table. It stores the VNF type and corresponding sub-DG,\r
 975 which are used to get the running configuration of a device. The ``module``\r
 976 and ``DG_RPC`` are used to identify the DG from the SVC\_LOGIC table. The\r
 977 ``protocol`` is used to store the protocol defined for retrieving\r
 978 configuration. If a mapping between the VNF type and the DG does not\r
 979 exist in this table, then actions such as Audit and Sync fail with the\r
 980 error message 'Device Interfacing DG not available'.\r
 981 \r
 982 DEVICE\_INTERFACE\_PROTOCOL Parameters\r
 983 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\r
 984 \r
 985 +---------------------------------------+--------------------------+\r
 986 | **Parameter Name**                    | **Example Value**        |\r
 987 +=======================================+==========================+\r
 988 | **device\_interface\_protocol\_id**   | 4                        |\r
 989 +---------------------------------------+--------------------------+\r
 990 | **vnf\_type**                         | vDBE-V                   |\r
 991 +---------------------------------------+--------------------------+\r
 992 | **protocol**                          | NETCONF-XML              |\r
 993 +---------------------------------------+--------------------------+\r
 994 | **module**                            | APPC                     |\r
 995 +---------------------------------------+--------------------------+\r
 996 | **dg\_rpc**                           | getDeviceRunningConfig   |\r
 997 +---------------------------------------+--------------------------+\r
 998 \r
 999 CONFIG FILES\r
1000 ~~~~~~~~~~~~\r
1001 \r
1002 The CONFIG\_FILES table is used by the several configuration DGs, using\r
1003 a legacy configuration API, to store artifacts from SDC, configuration\r
1004 data from requests, and configurations to be downloaded to VNFs.\r
1005 \r
1006 CONFIG\_FILES Parameters\r
1007 ^^^^^^^^^^^^^^^^^^^^^^^^\r
1008 \r
1009 +-----------------------------+----------------------------+\r
1010 | **Parameter Name**          | **Example Value**          |\r
1011 +=============================+============================+\r
1012 | **config\_file\_id**        | 24                         |\r
1013 +-----------------------------+----------------------------+\r
1014 | **external\_version**       |                            |\r
1015 +-----------------------------+----------------------------+\r
1016 | **data\_source**            | Configurator               |\r
1017 +-----------------------------+----------------------------+\r
1018 | **creation\_date**          | 6/9/2016 11:16:57 AM       |\r
1019 +-----------------------------+----------------------------+\r
1020 | **service\_instance\_id**   | ibcx0001vm001              |\r
1021 +-----------------------------+----------------------------+\r
1022 | **vnf\_type**               | ISBC                       |\r
1023 +-----------------------------+----------------------------+\r
1024 | **vnfc\_type**              | vISBC - mmc                |\r
1025 +-----------------------------+----------------------------+\r
1026 | **file\_category**          | device\_configuration      |\r
1027 +-----------------------------+----------------------------+\r
1028 | **file\_name**              | orch\_config.json          |\r
1029 +-----------------------------+----------------------------+\r
1030 | **file\_content**           | (contains configuration)   |\r
1031 +-----------------------------+----------------------------+\r
1032 \r
1033 GET\_CONFIG\_TEMPLATE\r
1034 ~~~~~~~~~~~~~~~~~~~~~\r
1035 \r
1036 The GET\_CONFIG\_TEMPLATE table is used by the 'getDeviceRunningConfig'\r
1037 DG, which is used as a sub-DG for the Audit and Sync actions. It stores\r
1038 template data corresponding to the VNF type. Template data is only used\r
1039 when the protocol in DEVICE\_INTERFACING\_PROTOCOL table is set to\r
1040 'CLI'. Other protocols do not use this table. If Data does not exist in\r
1041 this table and protocol is set to 'CLI' then DG results in 'Error\r
1042 getting Template Data'.\r
1043 \r
1044 GET\_CONFIG\_TEMPLATE Parameters\r
1045 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\r
1046 \r
1047 +---------------------------------------+-----------------------------------------+\r
1048 | **Parameter Name**                    | **Example Value**                       |\r
1049 +=======================================+=========================================+\r
1050 | **get\_config\_template\_id**         | 1                                       |\r
1051 +---------------------------------------+-----------------------------------------+\r
1052 | **vnf\_type**                         | Generic                                 |\r
1053 +---------------------------------------+-----------------------------------------+\r
1054 | **device\_interface\_protocol\_id**   | 3                                       |\r
1055 +---------------------------------------+-----------------------------------------+\r
1056 | **xml\_processing**                   |                                         |\r
1057 +---------------------------------------+-----------------------------------------+\r
1058 | **xml\_protocol**                     |                                         |\r
1059 +---------------------------------------+-----------------------------------------+\r
1060 | **template**                          | Login\_Prompt: Matches "Login as:"...   |\r
1061 +---------------------------------------+-----------------------------------------+\r
1062 \r
1063 ASDC\_ARTIFACTS\r
1064 ~~~~~~~~~~~~~~~\r
1065 \r
1066 The ASDC\_ARTIFACTS table contains the model received from the SDC in\r
1067 YAML format. APP-C reads this model and identifies the order of the\r
1068 VNFCs and their resilience types.\r
1069 \r
1070 ASDC\_ARTIFACTS parameters\r
1071 ^^^^^^^^^^^^^^^^^^^^^^^^^^\r
1072 \r
1073 +--------------------------------+------------------------+\r
1074 | **Parameter Name**             | **Example Value**      |\r
1075 +================================+========================+\r
1076 | **asdc\_artifacts\_id**        | 1                      |\r
1077 +--------------------------------+------------------------+\r
1078 | **service\_uuid**              | Service-uuid           |\r
1079 +--------------------------------+------------------------+\r
1080 | **distribution\_id**           | Distribution-ID        |\r
1081 +--------------------------------+------------------------+\r
1082 | **service\_name**              | Test                   |\r
1083 +--------------------------------+------------------------+\r
1084 | **service\_description**       | Test                   |\r
1085 +--------------------------------+------------------------+\r
1086 | **resource\_uuid**             | Resource-uuid          |\r
1087 +--------------------------------+------------------------+\r
1088 | **resource\_instance\_name**   | vSCP                   |\r
1089 +--------------------------------+------------------------+\r
1090 | **resource\_name**             | vSCP                   |\r
1091 +--------------------------------+------------------------+\r
1092 | **resource\_version**          | 1.0                    |\r
1093 +--------------------------------+------------------------+\r
1094 | **resource\_type**             | VF                     |\r
1095 +--------------------------------+------------------------+\r
1096 | **artifact\_uuid**             | Artifact-uuid          |\r
1097 +--------------------------------+------------------------+\r
1098 | **artifact\_type**             | TOPOLOGY               |\r
1099 +--------------------------------+------------------------+\r
1100 | **artifact\_version**          | 1                      |\r
1101 +--------------------------------+------------------------+\r
1102 | **artifact\_description**      | VNF Dependency Model   |\r
1103 +--------------------------------+------------------------+\r
1104 | **internal\_version**          | 0                      |\r
1105 +--------------------------------+------------------------+\r
1106 | **creation\_date**             | 2016-11-17 10:10:18    |\r
1107 +--------------------------------+------------------------+\r
1108 | **artifact\_name**             | Scp-template.yml       |\r
1109 +--------------------------------+------------------------+\r
1110 | **artifact\_content**          | <Content>              |\r
1111 +--------------------------------+------------------------+\r
1112 \r
1113 Sequence Generator API\r
1114 ======================\r
1115 \r
1116 The Sequence Generator API generates the steps of execution for LCM\r
1117 operations at minute-level. This API is exposed using the following\r
1118 two endpoints:\r
1119 \r
1120 -  DG plug-in\r
1121 \r
1122 -  REST API\r
1123 \r
1124 The Sequence Generator API takes an input file in JSON format and,\r
1125 based on the parameters defined in the input file, generates an\r
1126 output file.\r
1127 \r
1128 This chapter comprises the following topics:\r
1129 \r
1130 -  Sample input file\r
1131 \r
1132 -  Sample output file\r
1133 \r
1134 -  Supported actions\r
1135 \r
1136     The input file comprises:\r
1137 \r
1138 -  Request information\r
1139 \r
1140 -  Inventory information\r
1141 \r
1142 All these sections of the input file and the parameters used are\r
1143 explained in the subsequent sections.\r
1144 \r
1145 Sample Input File\r
1146 -----------------\r
1147 \r
1148 ::\r
1149 \r
1150         {\r
1151           "request-info": {\r
1152                 "action": "Stop",\r
1153                 "action-level": "vm",\r
1154                 "action-identifier": {\r
1155                   "vnf-id": "abc"\r
1156                 },\r
1157                 "payload":  " {\"vnf-host-ip-address\": \"10.147.124.163\" }"\r
1158           },\r
1159           "inventory-info": {\r
1160                 "vnf-info": {\r
1161                   "vnf-id" : "abc",\r
1162                   "vnf-name": "vSCP",\r
1163                   "vnf-type": "vSCP",\r
1164                   "vnf-version" : "1.0",\r
1165                   "vm": [\r
1166                         {\r
1167                           "vserver-id" : "be_vserverid1",\r
1168                           "vnfc":\r
1169                           {\r
1170                                 "vnfc-type": "BE",\r
1171                                 "vnfc-name": "BE - Name"\r
1172                           }\r
1173                         },\r
1174                         {\r
1175                           "vserver-id" : "fe_vserverid1",\r
1176                           "vnfc":\r
1177                           {\r
1178                                 "vnfc-type": "FE",\r
1179                                 "vnfc-name": "FE - Name"\r
1180                           }\r
1181                         },\r
1182                         {\r
1183                           "vserver-id" : "smp_vserverid1",\r
1184                           "vnfc":\r
1185                           {\r
1186                                 "vnfc-type": "SMP",\r
1187                                 "vnfc-name": "SMP - Name"\r
1188                           }\r
1189                         }\r
1190                   ]\r
1191                 }\r
1192           }\r
1193         }\r
1194 \r
1195 \r
1196 Parameters\r
1197 ~~~~~~~~~~\r
1198 \r
1199 This section explains the parameters used in the Sequence Generator\r
1200 API input file.\r
1201 \r
1202 +-----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------+-----------------+\r
1203 | **Parameter name**          | **Description**                                                                                                                                                               | **Possible values**                   | **Required?**   |\r
1204 +=============================+===============================================================================================================================================================================+=======================================+=================+\r
1205 | **Request Information**                                                                                                                                                                                                                                               |\r
1206 +-----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------+-----------------+\r
1207 | action                      | The action to be executed by Sequence Generator API.                                                                                                                          | Start,Stop                            | Y               |\r
1208 +-----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------+-----------------+\r
1209 | action-level                | Represents the level for the action such as, vm, vnfc.                                                                                                                        | Vnf,vnfc,vm,vf-module                 | Y               |\r
1210 +-----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------+-----------------+\r
1211 | 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
1212 +-----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------+-----------------+\r
1213 | vnf-id                      | Identifies the VNF instance to which this action is to be applied. vnf-id uniquely identifies the service-instance.                                                           | String                                | N               |\r
1214 +-----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------+-----------------+\r
1215 | payload                     | An action-specific open-format field. The payload can be any valid JSON string value.                                                                                         | AICIdentity and vnf-host-ip-address   | N               |\r
1216 +-----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------+-----------------+\r
1217 | **Inventory Information**                                                                                                                                                                                                                                             |\r
1218 +-----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------+-----------------+\r
1219 | vnfInfo                     | Represents the VNF information to which this action is to be applied.                                                                                                         | String                                | Y               |\r
1220 +-----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------+-----------------+\r
1221 | vnf-id                      | Identifies the VNF instance to which this action is to be applied. vnf-id uniquely identifies the service-instance.                                                           | String                                | N               |\r
1222 +-----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------+-----------------+\r
1223 | vnf-name                    | Identifies the VNF instance to which this action is to be applied.                                                                                                            | vSCP                                  | N               |\r
1224 +-----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------+-----------------+\r
1225 | vnf-type                    | Represents the type of the VNF instance.                                                                                                                                      | vSCP                                  | N               |\r
1226 +-----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------+-----------------+\r
1227 | vnf-version                 | Represents the version of the VNF instance.                                                                                                                                   | Alphanumeric                          | N               |\r
1228 +-----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------+-----------------+\r
1229 | vm                          | Represents the VM information to which this action is to be applied.                                                                                                          | List of VMs                           | Y               |\r
1230 +-----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------+-----------------+\r
1231 | vserver-id                  | Identifies a specific VM instance to which this action is to be applied.                                                                                                      | Alpha-numeric unique ID               | Y               |\r
1232 +-----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------+-----------------+\r
1233 | vnfc                        | Represents the VNFC information to which this action is to be applied.                                                                                                        | vnfc-type, vnfc-name                  | N               |\r
1234 +-----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------+-----------------+\r
1235 | vnfc-type                   | Represents the type of the VNFC instance.                                                                                                                                     | FE,BE,SMP                             | N               |\r
1236 +-----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------+-----------------+\r
1237 | vnfc-name                   | Identifies the VNFC instance to which this action is to be applied.                                                                                                           | FE-Name, BE-Name, SMP-Name            | N               |\r
1238 +-----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------+-----------------+\r
1239 \r
1240 Sample Output file\r
1241 ------------------\r
1242 \r
1243 ::\r
1244 \r
1245         [{\r
1246                 "transactionId": 1,\r
1247                 "action": "Stop",\r
1248                 "action-level": "vm",\r
1249                 "action-identifier": {\r
1250                         "vserver-id": "be_vserverid1"\r
1251                 },\r
1252                 "payload": " {\"vnf-host-ip-address\": \"10.147.124.163\" }",\r
1253                 "responses": [{\r
1254                         "response-message": "failure",\r
1255                         "response-action": {\r
1256                                 "ignore": "true"\r
1257                         }\r
1258                 }]\r
1259         },\r
1260         {\r
1261                 "transactionId": 2,\r
1262                 "action": "Stop",\r
1263                 "action-level": "vm",\r
1264                 "action-identifier": {\r
1265                         "vserver-id": "fe_vserverid1"\r
1266                 },\r
1267                 "payload": " {\"vnf-host-ip-address\": \"10.147.124.163\" }",\r
1268                 "responses": [{\r
1269                         "response-message": "failure",\r
1270                         "response-action": {\r
1271                                 "ignore": "true"\r
1272                         }\r
1273                 }]\r
1274         },\r
1275         {\r
1276                 "transactionId": 3,\r
1277                 "action": "Stop",\r
1278                 "action-level": "vm",\r
1279                 "action-identifier": {\r
1280                         "vserver-id": "smp_vserverid1"\r
1281                 },\r
1282                 "payload": " {\"vnf-host-ip-address\": \"10.147.124.163\" }",\r
1283                 "responses": [{\r
1284                         "response-message": "failure",\r
1285                         "response-action": {\r
1286                                 "ignore": "true"\r
1287                         }\r
1288                 }]\r
1289         }\r
1290         ]\r
1291 \r
1292 \r
1293 Supported Actions\r
1294 -----------------\r
1295 \r
1296 The following actions are supported for the Sequence Generator API\r
1297 for the Amsterdam release:\r
1298 \r
1299 -  Generate Runtime Sequence Flow for Start Action with no dependency\r
1300    model\r
1301 \r
1302 -  Generate Runtime Sequence Flow for Stop Action with no dependency\r
1303    model\r
1304 \r
1305 .. |image0| image:: media/AppCDeployment.png\r
1306    :width: 6.50000in\r
1307    :height: 2.55903in\r
1308 .. |image1| image:: media/AppCApidoxExplorer.png\r
1309    :width: 6.50000in\r
1310    :height: 4.83611in\r
1311 .. |image2| image:: media/AppCApidoxExplorer2.png\r
1312    :width: 6.50000in\r
1313    :height: 5.50139in\r
1314 .. |image3| image:: media/AppCApidoxExplorer3.png\r
1315    :width: 6.50000in\r
1316    :height: 5.65347in\r
1317 .. |image4| image:: media/AppCApidoxExplorer4.png\r
1318    :width: 6.50000in\r
1319    :height: 6.62292in\r
1320 .. |image5| image:: media/AppCArchitectureDiagram.png\r
1321    :width: 6.50000in\r
1322    :height: 3.40347in\r
1323 .. |image6| image:: media/AppCDGOrchestratorArchitecture.png\r
1324    :width: 6.36597in\r
1325    :height: 3.72903in\r