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 Netconf Adapter\r
 352 ^^^^^^^^^^^^^^^\r
 353 \r
 354     The Adapter is responsible for configuration tasks, using XML\r
 355     format, for VNFs supporting Netconf API.\r
 356 \r
 357 IAAS Adapter \r
 358 ^^^^^^^^^^^^^\r
 359 \r
 360     The IAAS Adapter connects APPC with the OpenStack controllers to\r
 361     perform various operations on VMs and VNFs such as Restart, Migrate,\r
 362     and Rebuild. The IAAS Adapter integrates as a DG plugin, while the\r
 363     DGs call the services exposed by the adapter.\r
 364 \r
 365 SSH (XML/CLI) Adapter\r
 366 ^^^^^^^^^^^^^^^^^^^^^\r
 367 \r
 368     A custom adapter that enables connection to a VNF using an SSH\r
 369     session. It is designed to support CLI and XML protocols, including\r
 370     Netconf. It is used to load configurations and retrieve the running\r
 371     configuration.\r
 372 \r
 373 Chef Adaptor\r
 374 ^^^^^^^^^^^^\r
 375 \r
 376     This adaptor incorporates a client for an external Chef server,\r
 377     which connects to VNF NB APIs. The adaptor enables APPC to operate\r
 378     cookbooks (Chef recipes) to perform various LCM operations over\r
 379     VNFs, connected to the Chef server.\r
 380 \r
 381 Ansible Adapter\r
 382 ^^^^^^^^^^^^^^^\r
 383 \r
 384     This adaptor incorporates a client for an external Ansible server,\r
 385     which connects to VNF NB APIs. The adaptor enables APPC to operate\r
 386     playbooks to perform various LCM operations over VNFs connected to\r
 387     the Ansible server.\r
 388 \r
 389 Cross Cutting Components\r
 390 ~~~~~~~~~~~~~~~~~~~~~~~~\r
 391 \r
 392 The Cross Cutting Component services operate across all APPC modules.\r
 393 \r
 394 Configuration\r
 395 ^^^^^^^^^^^^^\r
 396 \r
 397 Used to configure operational parameters of APPC modules based on\r
 398 function-specific configuration files, for example:\r
 399 \r
 400 -  ``log4j.properties`` for the logging service\r
 401 \r
 402 -  ``appc.properties`` for core APPC-related configuration\r
 403 \r
 404 -  ``dblib.properties`` for managing APPC database-related configuration\r
 405 \r
 406 -  ``aaiclient.properties`` for managing A&AI-related configuration\r
 407 \r
 408 KPI Service\r
 409 ^^^^^^^^^^^\r
 410 \r
 411 This Cross Cutting component manages KPI measurement, storage and\r
 412 reporting.\r
 413 \r
 414 Enable matrix logs to log the number of hits of the configured method of\r
 415 APPC, by configuring the following properties in ``appc.properties:``::\r
 416 \r
 417    metric.enabled=<true>\r
 418    schedule.policy.metric.start.time=<time value in hhmmss>\r
 419    schedule.policy.metric.period = 60(interval in seconds)\r
 420 \r
 421 Security Service\r
 422 ^^^^^^^^^^^^^^^^\r
 423 \r
 424 This component implements AAF (Authentication and Authorization\r
 425 Framework) for APPC API security. The user provides a user name and\r
 426 password in the request that will be validated against centralize AAF.\r
 427 [Note: For Amsterdam Releasse, AAF is not used]\r
 428 \r
 429 Logging Service\r
 430 ^^^^^^^^^^^^^^^\r
 431 \r
 432 Implements EELF (Event and Error Logging Framework) to manage and\r
 433 generate logs (refer to Logging section).\r
 434 \r
 435 Data Access Service\r
 436 ^^^^^^^^^^^^^^^^^^^\r
 437 \r
 438 Provides access to the internal data store.\r
 439 \r
 440 Transactions store\r
 441 ~~~~~~~~~~~~~~~~~~\r
 442 \r
 443 For each operation request procedure that completes or terminates,\r
 444 APPC generates and stores an accurate transaction record in its\r
 445 internal database, including:\r
 446 \r
 447 -  Timestamp\r
 448 \r
 449 -  Request ID\r
 450 \r
 451 -  Start time\r
 452 \r
 453 -  End time\r
 454 \r
 455 -  VF\_ID\r
 456 \r
 457 -  VF\_type\r
 458 \r
 459 -  Sub-component (optional) e.g. VFC\_ID/VM UUID\r
 460 \r
 461 -  Operation: for example Start, Configure, etc.\r
 462 \r
 463 -  Result: Success/Error code and description, as published to the\r
 464    initiator\r
 465 \r
 466 Interfaces Summary\r
 467 ~~~~~~~~~~~~~~~~~~\r
 468 \r
 469 +-------------------+------------+-------------------------+-------------------+-------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+\r
 470 | **Source**        | **Flow**   | **Destination**         | **Service**       | **Port**    | **Purpose / Comments**                                                                                                                                                     |\r
 471 +===================+============+=========================+===================+=============+============================================================================================================================================================================+\r
 472 | APPC              |    ->      | A&AI                    | REST              | 8443        | APPC retrieves and updates the VNF data in AAI.                                                                                                                            |\r
 473 +-------------------+------------+-------------------------+-------------------+-------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+\r
 474 | APPC              |    ->      | SLI                     | Java (internal)   | N/A         | APPC sends the LCM API request to SLI for DG execution                                                                                                                     |\r
 475 +-------------------+------------+-------------------------+-------------------+-------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+\r
 476 | APPC              |    ->      | South-bound Adapters    | Java (internal)   | N/A         | APPC interacts  with southbound adapters for VNF Lifecycle Management Actions                                                                                              |\r
 477 +-------------------+------------+-------------------------+-------------------+-------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+\r
 478 | APPC              |    ->      | NETCONF                 | NETCONF           | 830 or 22   | NETCONF Adapter communicates on port 830 (default) or port 22 (SSH – if set up)                                                                                            |\r
 479 +-------------------+------------+-------------------------+-------------------+-------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+\r
 480 | APPC              |    ->      | Chef Server             | HTTP/HTTPS        | 80/443      | Chef adapter communicate on port 80 (HTTP) or port 443 (HTTPS)                                                                                                             |\r
 481 +-------------------+------------+-------------------------+-------------------+-------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+\r
 482 | APPC              |    ->      | Ansible Server          | HTTP              | 8000        | Port 8000 is used for communication between the APPC Ansible Adaptor and the Ansible Server.                                                                               |\r
 483 +-------------------+------------+-------------------------+-------------------+-------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+\r
 484 | APPC              |    ->      | MySQL                   | Java (internal)   | 3306        |                                                                                                                                                                            |\r
 485 +-------------------+------------+-------------------------+-------------------+-------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+\r
 486 | APPC              |    ->      | DG Builder              | Java (internal)   | 3000        |                                                                                                                                                                            |\r
 487 +-------------------+------------+-------------------------+-------------------+-------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+\r
 488 | APPC              |    ->      | MD-SAL, Apidoc, Karaf   | Java (internal)   | 8282        |                                                                                                                                                                            |\r
 489 +-------------------+------------+-------------------------+-------------------+-------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+\r
 490 | APPC              |    ->      | DMaaP                   | JMS               | 3904        | APPC sends the Asynchronous responses and Failure events to DMaaP Message Bus                                                                                              |\r
 491 +-------------------+------------+-------------------------+-------------------+-------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+\r
 492 | 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
 493 +-------------------+------------+-------------------------+-------------------+-------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+\r
 494 | SDC               |    ->      | APPC                    | DMaaP             | 3904        | APPC requests and receives notifications from SDC for VNF License Artifacts and TOSCA dependency models.                                                                   |\r
 495 +-------------------+------------+-------------------------+-------------------+-------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+\r
 496 | 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
 497 +-------------------+------------+-------------------------+-------------------+-------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+\r
 498 | OOM               |    ->      | APPC                    | DMaaP             | 3904        | APPC receives operational commands: Start, Graceful Stop.                                                                                                                  |\r
 499 |                   |            |                         |                   |             | APPC reports: status, KPIs.                                                                                                                                                |\r
 500 +-------------------+------------+-------------------------+-------------------+-------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+\r
 501 \r
 502 APPC Deployment \r
 503 ================\r
 504 \r
 505 Refer to the APPC Deployment documentation at\r
 506 http://onap.readthedocs.io/en/latest/submodules/appc/deployment.git/docs/index.html\r
 507 \r
 508 Application Controller VNF Onboarding\r
 509 =====================================\r
 510 \r
 511 LCM Command Execution Overview\r
 512 ------------------------------\r
 513 \r
 514 The Application Controller assumes that the A&AI instance it is\r
 515 configured with contains all the information it needs about\r
 516 VNF/VNFC/VMs, otherwise any request by the user to perform an action\r
 517 on a VNF will fail. The Application Controller uses a variety of SQL\r
 518 tables in order to perform actions on a VNF, all of which are\r
 519 described in Creation of DGs\r
 520 \r
 521 DGs are created using the Direct Graph Builder - Node Red graphical\r
 522 utility for DGs creation. DGs are then stored as XML files and loaded to\r
 523 APPC MySQL database. The DGs invoke the execution of Java code from\r
 524 different nodes.\r
 525 \r
 526 DGs are resolved according to LCM Action, API version, VNF Type, and VNF\r
 527 Version.\r
 528 \r
 529 The SLI framework is responsible for executing the DGs.\r
 530 \r
 531 Data Setup. \r
 532 ~~~~~~~~~~~~\r
 533 \r
 534 Initially, Application Controller should have a set of DGs designed\r
 535 for the specific VNF type. These DGs are stored in the SVC\_LOGIC\r
 536 table.\r
 537 \r
 538 After a user sends an action request to the controller, the\r
 539 Application Controller uses the VNF\_DG\_MAPPING table to map the\r
 540 requested action to a specific DG. If the mapping was successful,\r
 541 the input body is validated and the user receives a synchronous\r
 542 response containing an Accept or a Reject message to indicate\r
 543 whether the request was rejected or whether it was accepted and the\r
 544 controller initiated the DG flow.\r
 545 \r
 546 During the execution of a DG, the controller may use one or more SQL\r
 547 tables to fetch or store data. For example, in order to perform a\r
 548 ConfigModify action, the controller needs to fetch a username and\r
 549 password to connect to the VNF and change its configuration.\r
 550 \r
 551 ALL tables used during DG execution are described below.\r
 552 \r
 553 Request execution\r
 554 -----------------\r
 555 \r
 556 Following initial request validation, APPC queries the A&AI inventory to\r
 557 acquire all the required information regarding topology of VNF/VNFC/VMs,\r
 558 operational status and operational data of the requested VNF instance. A\r
 559 missing target VF instance or any missing mandatory parameter in A&AI\r
 560 generate a rejection.\r
 561 \r
 562 After acquiring the VNF type from A&AI, APPC uses the VNF\_DG\_MAPPING\r
 563 table to map the requested action to a specific DG. No such DG located\r
 564 in the table generates a Reject response to the user.\r
 565 \r
 566 The Dispatcher state machine applies operation policies. A policy\r
 567 allowing execution generates an Accept response to the user. Not\r
 568 allowing execution generates a Reject response.\r
 569 \r
 570 If the first two steps were successful, the controller initiates the\r
 571 appropriate DG.\r
 572 \r
 573 During the execution of a DG, the controller may use one or more SQL\r
 574 tables to fetch or store data. For example, to perform a ConfigModify\r
 575 action, the controller needs to fetch a username and password to connect\r
 576 to the VNF and change its configuration.\r
 577 \r
 578 `Data Setup <#_Data_Setup>`__ describes the tables used during DG\r
 579 execution.\r
 580 \r
 581 If APPC is forced stopped while it is executing an LCM request, it might\r
 582 take some time to terminate all the threads that are being executed. In\r
 583 addition, the old threads might start to execute again once the APPC is\r
 584 restarted. The time when these treads start to execute again even after\r
 585 an APPC restart is dependent on the LCM request executed by the threads\r
 586 in the LCM queue and the ThreadPool size. To avoid this, it is\r
 587 recommended that:\r
 588 \r
 589 -  Start APPC only after a while to ensure that the interrupted threads\r
 590    are not executed again.\r
 591 \r
 592 -  Do not execute the OAM-Forceful Stop command if the system is\r
 593    executing an LCM request. Let the system operate in Maintenance mode.\r
 594 \r
 595    1. .. rubric:: Creation of DGs\r
 596          :name: creation-of-dgs\r
 597 \r
 598 DGs are created using the Direct Graph Builder - Node Red graphical\r
 599 utility for DGs creation. DGs are then stored as XML files and loaded to\r
 600 APPC MySQL database. The DGs invoke the execution of Java code from\r
 601 different nodes.\r
 602 \r
 603 At runtime, DGs are resolved according to LCM Action, API version, VNF\r
 604 Type, and VNF Version.\r
 605 \r
 606 The SLI framework is responsible for executing the DGs.\r
 607 \r
 608 Data Setup\r
 609 ----------\r
 610 \r
 611 APPC uses MySQL database as a persistent store. This section describes\r
 612 the tables in general and the tables that require data to be set up\r
 613 before sending a request.\r
 614 \r
 615 SVC\_LOGIC Table\r
 616 ~~~~~~~~~~~~~~~~\r
 617 \r
 618 SVC\_LOGIC table stores all NodeRed DGs invoked by actions executed by\r
 619 APPC. The SLI framework uses this table for running the DG. If the DG\r
 620 does not exist in this table, the SLI framework returns a 'DG not found'\r
 621 error.\r
 622 \r
 623 SVC\_LOGIC Parameters\r
 624 ^^^^^^^^^^^^^^^^^^^^^\r
 625 \r
 626 +----------------------+----------------------+\r
 627 | **Parameter Name**   | **Example Values**   |\r
 628 +======================+======================+\r
 629 | **module**           | APPC                 |\r
 630 +----------------------+----------------------+\r
 631 | **rpc**              | Generic\_Audit       |\r
 632 +----------------------+----------------------+\r
 633 | **version**          | 2.0.0                |\r
 634 +----------------------+----------------------+\r
 635 | **mode**             | sync                 |\r
 636 +----------------------+----------------------+\r
 637 | **active**           | N                    |\r
 638 +----------------------+----------------------+\r
 639 | **graph**            | <BLOB>               |\r
 640 +----------------------+----------------------+\r
 641 \r
 642 **module, rpc, version**\r
 643 \r
 644 The ``module``, ``rpc``, and ``version`` parameters uniquely identify a Directed\r
 645 Graph (DG). The SLI framework uses these three parameters to invoke a DG\r
 646 or sub-DG. By convention, for the main DG, rpc is a combination of 'VNF\r
 647 type' (the generic type applied to all VNFs) followed by '\_' and\r
 648 'action'. This is the default convention; resolution of the DG for\r
 649 specific actions is handled individually in the relevant forthcoming\r
 650 sections.\r
 651 \r
 652 **mode**\r
 653 \r
 654 The DG execution node. This value is set to ‘sync’ for all APPC DGs.\r
 655 \r
 656 **active**\r
 657 \r
 658 This flag is the value of either 'Y' or 'N'. This flag is only used if\r
 659 specific version of DG is not mentioned while calling DG. If version of\r
 660 DG is not mentioned SLI framework will look for DG with active Flag set\r
 661 to 'Y' and execute it if found.\r
 662 \r
 663 **graph**\r
 664 \r
 665 This is actual graph invoked by SLI framework. The data type is SQL\r
 666 BLOB.\r
 667 \r
 668 VNF\_DG\_MAPPING\r
 669 ~~~~~~~~~~~~~~~~\r
 670 \r
 671 The VNF\_DG\_MAPPING table stores the VNF and its corresponding DG. This\r
 672 is used by the DG resolver logic of the Dispatcher to map the DG to the\r
 673 requested action. Only the mapping is stored; the actual DG is stored in\r
 674 the SVC\_LOGIC table.\r
 675 \r
 676 The DG resolver logic uses a combination of action, api\_version and\r
 677 vnf\_type to retrieve the DG details: dg\_name (rpc column of SVC\_LOGIC\r
 678 table), dg\_version and dg\_module.\r
 679 \r
 680 The module, rpc and version uniquely identify the DG.\r
 681 \r
 682 The following assigned priority resolves the VNF DG:\r
 683 \r
 684 1. ``action``\r
 685 \r
 686 2. ``api_version``\r
 687 \r
 688 3. ``vnf_type``\r
 689 \r
 690 4. ``vnf_version``\r
 691 \r
 692 Blank, null or ‘\*’ values in ``api_version``, ``vnf_type`` and ``vnf_version``\r
 693 are matched with any values by the DG resolver. For example, a generic\r
 694 DG which can be invoked on any type of VNF ``vnf_type`` can be blank /\r
 695 null or \*. The DG resolver logic first tries to match a specific DG,\r
 696 and if this is not found, then look for a generic match using ‘\*’. For\r
 697 example as illustrated in the Example values in below table, an entry\r
 698 for the Test action and vnf\_type VSBG is specific, so it is only used\r
 699 for VNFs of type VSBG, whereas for the Sync action the same DG is used\r
 700 for any type of VNF and any version.\r
 701 \r
 702 VNF\_DG\_MAPPING Parameters\r
 703 ^^^^^^^^^^^^^^^^^^^^^^^^^^^\r
 704 \r
 705 +----------------------+----------------------+-----------------+\r
 706 | **Parameter Name**   | **Example Values**                     |\r
 707 +======================+======================+=================+\r
 708 | **action**           | Test                 | Sync            |\r
 709 +----------------------+----------------------+-----------------+\r
 710 | **api\_verson**      | 2                    |                 |\r
 711 +----------------------+----------------------+-----------------+\r
 712 | **vnf\_type**        | vSBG                 |                 |\r
 713 +----------------------+----------------------+-----------------+\r
 714 | **vnf\_version**     |                      |                 |\r
 715 +----------------------+----------------------+-----------------+\r
 716 | **dg\_name**         | vSBG\_Test           | Generic\_Sync   |\r
 717 +----------------------+----------------------+-----------------+\r
 718 | **dg\_version**      | 2.0.0.1              | 2.0.0           |\r
 719 +----------------------+----------------------+-----------------+\r
 720 | **dg\_module**       | APPC                 | APPC            |\r
 721 +----------------------+----------------------+-----------------+\r
 722 \r
 723 VNFC\_DG\_MAPPING\r
 724 ~~~~~~~~~~~~~~~~~\r
 725 \r
 726 VNFC\_DG\_MAPPING stores the VNFC and its corresponding DG. The DG\r
 727 resolver logic of the Dispatcher uses this to map the DG to the\r
 728 requested action. Only the mapping is stored; the actual DG is stored in\r
 729 the SVC\_LOGIC table.\r
 730 \r
 731 The DG resolver logic uses a combination of ``action``, ``api_version``,\r
 732 ``vnf_type``, and ``vnfc_type`` to retrieve the DG details: ``dg_name`` (rpc\r
 733 column of SVC\_LOGIC table), ``dg_version``, and ``dg_module``.\r
 734 \r
 735 The module, rpc and version uniquely identify the DG.\r
 736 \r
 737 The following assigned priority resolves the VNF DG:\r
 738 \r
 739 1. ``action``\r
 740 \r
 741 2. ``api_version``\r
 742 \r
 743 3. ``vnf_type``\r
 744 \r
 745 4. ``vnfc_type``\r
 746 \r
 747 The DG resolver matches blank, null or ‘\*’ values in ``api_version`` ,\r
 748 ``vnf_type`` and ``vnfc_type`` with any values. For example, a generic DG\r
 749 which can be invoked on any type of VNFC 'vnfc\_type' can be blank /\r
 750 null or \*. The DG resolver logic first tries to match a specific DG. If\r
 751 this is not found, the DG resolver looks for a generic match using ‘\*’.\r
 752 \r
 753 VNFC\_DG\_MAPPING parameters\r
 754 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^\r
 755 \r
 756 +----------------------+---------------------+\r
 757 | **Parameter Name**   | **Example Value**   |\r
 758 +======================+=====================+\r
 759 | **action**           |                     |\r
 760 +----------------------+---------------------+\r
 761 | **api\_version**     |                     |\r
 762 +----------------------+---------------------+\r
 763 | **vnf\_type**        |                     |\r
 764 +----------------------+---------------------+\r
 765 | **vnfc\_type**       |                     |\r
 766 +----------------------+---------------------+\r
 767 | **dg\_name**         |                     |\r
 768 +----------------------+---------------------+\r
 769 | **dg\_version**      |                     |\r
 770 +----------------------+---------------------+\r
 771 | **dg\_module**       |                     |\r
 772 +----------------------+---------------------+\r
 773 \r
 774 DEVICE\_AUTHENTICATION\r
 775 ~~~~~~~~~~~~~~~~~~~~~~\r
 776 \r
 777 The DEVICE\_AUTHENTICATION table stores device authentication\r
 778 details. It is used by actions such as Audit and Sync which connect\r
 779 with VNFs. This table stores a record that corresponds to each VNF\r
 780 type, so ``vnf_type`` is unique.\r
 781 \r
 782 Username, password and port\_number are fields corresponding to\r
 783 ``vnf_type``.\r
 784 \r
 785 DEVICE\_AUTHENTICATION Parameters\r
 786 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\r
 787 \r
 788 +----------------------------------+---------------------+\r
 789 | **Parameter Name**               | **Example Value**   |\r
 790 +==================================+=====================+\r
 791 | **device\_authentication\_id**   | 41                  |\r
 792 +----------------------------------+---------------------+\r
 793 | **vnf\_type**                    | vDBE-V              |\r
 794 +----------------------------------+---------------------+\r
 795 | **user\_name**                   | root                |\r
 796 +----------------------------------+---------------------+\r
 797 | **password**                     | <password>          |\r
 798 +----------------------------------+---------------------+\r
 799 | **port\_number**                 | 22                  |\r
 800 +----------------------------------+---------------------+\r
 801 \r
 802 VNF\_LOCK\_MANAGEMENT\r
 803 ~~~~~~~~~~~~~~~~~~~~~\r
 804 \r
 805 The VNF\_LOCK\_MANAGEMENT table is used to persist data for vnf\r
 806 locking. APPC locks the vnf id when actions start executing on that\r
 807 vnf id. This table stores vnf\_id i.e. resource\_id  along with\r
 808 owner , expiration\_time or timeout. Before execution of request,\r
 809 the dispatcher checks if VNF\_ID is already locked by another action\r
 810 in execution. If VNF\_ID is not locked, the dispatcher will locks it\r
 811 or else returns a VNF locked error to caller.\r
 812 \r
 813 VNF\_LOCK\_MANAGEMENT Parameters\r
 814 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\r
 815 \r
 816 +----------------------+---------------------+\r
 817 | **Parameter Name**   | **Example Value**   |\r
 818 +======================+=====================+\r
 819 | **resource\_id**     | AUDIT\_1652         |\r
 820 +----------------------+---------------------+\r
 821 | **owner\_id**        | vDBE-V              |\r
 822 +----------------------+---------------------+\r
 823 | **updated**          | 1474457140000       |\r
 824 +----------------------+---------------------+\r
 825 | **timeout**          | 0                   |\r
 826 +----------------------+---------------------+\r
 827 | **ver**              | 22                  |\r
 828 +----------------------+---------------------+\r
 829 \r
 830 This table do not require any initial setup.\r
 831 \r
 832 VNF\_STATE\_MANAGEMENT\r
 833 ~~~~~~~~~~~~~~~~~~~~~~\r
 834 \r
 835 The VNF\_STATE\_MANAGEMENT table is used to store the operational state\r
 836 of VNF\_ID, whether it is stable or unstable. It stores state, owner and\r
 837 updated time (in milliseconds). This table does not require any initial\r
 838 setup.\r
 839 \r
 840 VNF\_STATE\_MANAGEMENT Parameters\r
 841 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\r
 842 \r
 843 +----------------------+-------------------------------------+\r
 844 | **Parameter Name**   | **Example Value**                   |\r
 845 +======================+=====================================+\r
 846 | **vnf\_if**          | ASHISH\_VSBG\_VNFS\_1787            |\r
 847 +----------------------+-------------------------------------+\r
 848 | **state**            | STABLE                              |\r
 849 +----------------------+-------------------------------------+\r
 850 | **owner\_id**        | ORIG\_1787@REQ\_1787@SUBREQ\_1787   |\r
 851 +----------------------+-------------------------------------+\r
 852 | **updated**          | 1474457140000                       |\r
 853 +----------------------+-------------------------------------+\r
 854 | **timeout**          | 0                                   |\r
 855 +----------------------+-------------------------------------+\r
 856 | **ver**              | 22                                  |\r
 857 +----------------------+-------------------------------------+\r
 858 \r
 859 UPLOAD\_CONFIG\r
 860 ~~~~~~~~~~~~~~\r
 861 \r
 862 The UPLOAD\_CONFIG table is used by configuration management actions\r
 863 such as Audit, Sync, ConfigModify, Terminate, and similar. It stores\r
 864 device configuration: one row or record corresponds to one VNFC, so\r
 865 therefore a VNF that has multiple VNFCs has multiple rows in the\r
 866 table.\r
 867 \r
 868 The UPLOAD\_CONFIG table stores configuration as the following\r
 869 types:\r
 870 \r
 871 -  ``Current``\r
 872 \r
 873 -  ``Running``\r
 874 \r
 875 -  ``Historic``\r
 876 \r
 877 The ``config_indicator`` column denotes the type of configuration,\r
 878 where a null value denotes ``Historic`` configuration. For a single VNFC\r
 879 there should only be one ``Current`` and one ``Running`` configuration , but\r
 880 there can be multiple Historic configurations. This table does not\r
 881 require any initial setup.\r
 882 \r
 883 UPLOAD\_CONFIG Parameters\r
 884 ^^^^^^^^^^^^^^^^^^^^^^^^^\r
 885 \r
 886 +----------------------------+-------------------------+-------------------------+\r
 887 | **Parameter Name**         | **Example Values**                                |\r
 888 +============================+=========================+=========================+\r
 889 | **upload\_config\_id**     | 63                      | 67                      |\r
 890 +----------------------------+-------------------------+-------------------------+\r
 891 | **request\_id**            | 3                       | REQ\_1690               |\r
 892 +----------------------------+-------------------------+-------------------------+\r
 893 | **originator\_id**         | 12345                   | ORIG\_1690              |\r
 894 +----------------------------+-------------------------+-------------------------+\r
 895 | **service\_description**   | abcde                   | abcde                   |\r
 896 +----------------------------+-------------------------+-------------------------+\r
 897 | **action**                 | ConfigModify            | Sync                    |\r
 898 +----------------------------+-------------------------+-------------------------+\r
 899 | **upload\_date**           | 2016-08-01 14:30:40     | 2016-09-22 12:30:40     |\r
 900 +----------------------------+-------------------------+-------------------------+\r
 901 | **vnf\_id**                | AUDIT\_1767             | AUDIT\_1690             |\r
 902 +----------------------------+-------------------------+-------------------------+\r
 903 | **vnf\_name**              | GET\_RUN\_CONFIG\_VNF   | GET\_RUN\_CONFIG\_VNF   |\r
 904 +----------------------------+-------------------------+-------------------------+\r
 905 | **vm\_name**               | GET\_RUN\_CONFIG\_VNF   | GET\_RUN\_CONFIG\_VNF   |\r
 906 +----------------------------+-------------------------+-------------------------+\r
 907 | **vnf\_type**              | vDBE-V                  | vDBE-V                  |\r
 908 +----------------------------+-------------------------+-------------------------+\r
 909 | **vnfc\_type**             | vDBE-V2                 | vDBE-V1                 |\r
 910 +----------------------------+-------------------------+-------------------------+\r
 911 | **host\_ip\_address**      | 135.25.69.37            |                         |\r
 912 +----------------------------+-------------------------+-------------------------+\r
 913 | **config\_indicator**      | Current                 | Running                 |\r
 914 +----------------------------+-------------------------+-------------------------+\r
 915 | **pending\_delete**        |                         |                         |\r
 916 +----------------------------+-------------------------+-------------------------+\r
 917 | **content**                | Dummy\_current          | <Configuration>         |\r
 918 +----------------------------+-------------------------+-------------------------+\r
 919 \r
 920 DEVICE\_INTERFACE\_PROTOCOL\r
 921 ~~~~~~~~~~~~~~~~~~~~~~~~~~~\r
 922 \r
 923 The DEVICE\_INTERFACE\_PROTOCOL table stores the VNF type and\r
 924 corresponding sub-DG used to get the running configuration of a device.\r
 925 The 'getRunningConfig' DG, which is a sub-DG called by Audit and Sync\r
 926 DG, uses this table. It stores the VNF type and corresponding sub-DG,\r
 927 which are used to get the running configuration of a device. The ``module``\r
 928 and ``DG_RPC`` are used to identify the DG from the SVC\_LOGIC table. The\r
 929 ``protocol`` is used to store the protocol defined for retrieving\r
 930 configuration. If a mapping between the VNF type and the DG does not\r
 931 exist in this table, then actions such as Audit and Sync fail with the\r
 932 error message 'Device Interfacing DG not available'.\r
 933 \r
 934 DEVICE\_INTERFACE\_PROTOCOL Parameters\r
 935 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\r
 936 \r
 937 +---------------------------------------+--------------------------+\r
 938 | **Parameter Name**                    | **Example Value**        |\r
 939 +=======================================+==========================+\r
 940 | **device\_interface\_protocol\_id**   | 4                        |\r
 941 +---------------------------------------+--------------------------+\r
 942 | **vnf\_type**                         | vDBE-V                   |\r
 943 +---------------------------------------+--------------------------+\r
 944 | **protocol**                          | NETCONF-XML              |\r
 945 +---------------------------------------+--------------------------+\r
 946 | **module**                            | APPC                     |\r
 947 +---------------------------------------+--------------------------+\r
 948 | **dg\_rpc**                           | getDeviceRunningConfig   |\r
 949 +---------------------------------------+--------------------------+\r
 950 \r
 951 CONFIG FILES\r
 952 ~~~~~~~~~~~~\r
 953 \r
 954 The CONFIG\_FILES table is used by the several configuration DGs, using\r
 955 a legacy configuration API, to store artifacts from SDC, configuration\r
 956 data from requests, and configurations to be downloaded to VNFs.\r
 957 \r
 958 CONFIG\_FILES Parameters\r
 959 ^^^^^^^^^^^^^^^^^^^^^^^^\r
 960 \r
 961 +-----------------------------+----------------------------+\r
 962 | **Parameter Name**          | **Example Value**          |\r
 963 +=============================+============================+\r
 964 | **config\_file\_id**        | 24                         |\r
 965 +-----------------------------+----------------------------+\r
 966 | **external\_version**       |                            |\r
 967 +-----------------------------+----------------------------+\r
 968 | **data\_source**            | Configurator               |\r
 969 +-----------------------------+----------------------------+\r
 970 | **creation\_date**          | 6/9/2016 11:16:57 AM       |\r
 971 +-----------------------------+----------------------------+\r
 972 | **service\_instance\_id**   | ibcx0001vm001              |\r
 973 +-----------------------------+----------------------------+\r
 974 | **vnf\_type**               | ISBC                       |\r
 975 +-----------------------------+----------------------------+\r
 976 | **vnfc\_type**              | vISBC - mmc                |\r
 977 +-----------------------------+----------------------------+\r
 978 | **file\_category**          | device\_configuration      |\r
 979 +-----------------------------+----------------------------+\r
 980 | **file\_name**              | orch\_config.json          |\r
 981 +-----------------------------+----------------------------+\r
 982 | **file\_content**           | (contains configuration)   |\r
 983 +-----------------------------+----------------------------+\r
 984 \r
 985 GET\_CONFIG\_TEMPLATE\r
 986 ~~~~~~~~~~~~~~~~~~~~~\r
 987 \r
 988 The GET\_CONFIG\_TEMPLATE table is used by the 'getDeviceRunningConfig'\r
 989 DG, which is used as a sub-DG for the Audit and Sync actions. It stores\r
 990 template data corresponding to the VNF type. Template data is only used\r
 991 when the protocol in DEVICE\_INTERFACING\_PROTOCOL table is set to\r
 992 'CLI'. Other protocols do not use this table. If Data does not exist in\r
 993 this table and protocol is set to 'CLI' then DG results in 'Error\r
 994 getting Template Data'.\r
 995 \r
 996 GET\_CONFIG\_TEMPLATE Parameters\r
 997 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\r
 998 \r
 999 +---------------------------------------+-----------------------------------------+\r
1000 | **Parameter Name**                    | **Example Value**                       |\r
1001 +=======================================+=========================================+\r
1002 | **get\_config\_template\_id**         | 1                                       |\r
1003 +---------------------------------------+-----------------------------------------+\r
1004 | **vnf\_type**                         | Generic                                 |\r
1005 +---------------------------------------+-----------------------------------------+\r
1006 | **device\_interface\_protocol\_id**   | 3                                       |\r
1007 +---------------------------------------+-----------------------------------------+\r
1008 | **xml\_processing**                   |                                         |\r
1009 +---------------------------------------+-----------------------------------------+\r
1010 | **xml\_protocol**                     |                                         |\r
1011 +---------------------------------------+-----------------------------------------+\r
1012 | **template**                          | Login\_Prompt: Matches "Login as:"...   |\r
1013 +---------------------------------------+-----------------------------------------+\r
1014 \r
1015 ASDC\_ARTIFACTS\r
1016 ~~~~~~~~~~~~~~~\r
1017 \r
1018 The ASDC\_ARTIFACTS table contains the model received from the SDC in\r
1019 YAML format. APP-C reads this model and identifies the order of the\r
1020 VNFCs and their resilience types.\r
1021 \r
1022 ASDC\_ARTIFACTS parameters\r
1023 ^^^^^^^^^^^^^^^^^^^^^^^^^^\r
1024 \r
1025 +--------------------------------+------------------------+\r
1026 | **Parameter Name**             | **Example Value**      |\r
1027 +================================+========================+\r
1028 | **asdc\_artifacts\_id**        | 1                      |\r
1029 +--------------------------------+------------------------+\r
1030 | **service\_uuid**              | Service-uuid           |\r
1031 +--------------------------------+------------------------+\r
1032 | **distribution\_id**           | Distribution-ID        |\r
1033 +--------------------------------+------------------------+\r
1034 | **service\_name**              | Test                   |\r
1035 +--------------------------------+------------------------+\r
1036 | **service\_description**       | Test                   |\r
1037 +--------------------------------+------------------------+\r
1038 | **resource\_uuid**             | Resource-uuid          |\r
1039 +--------------------------------+------------------------+\r
1040 | **resource\_instance\_name**   | vSCP                   |\r
1041 +--------------------------------+------------------------+\r
1042 | **resource\_name**             | vSCP                   |\r
1043 +--------------------------------+------------------------+\r
1044 | **resource\_version**          | 1.0                    |\r
1045 +--------------------------------+------------------------+\r
1046 | **resource\_type**             | VF                     |\r
1047 +--------------------------------+------------------------+\r
1048 | **artifact\_uuid**             | Artifact-uuid          |\r
1049 +--------------------------------+------------------------+\r
1050 | **artifact\_type**             | TOPOLOGY               |\r
1051 +--------------------------------+------------------------+\r
1052 | **artifact\_version**          | 1                      |\r
1053 +--------------------------------+------------------------+\r
1054 | **artifact\_description**      | VNF Dependency Model   |\r
1055 +--------------------------------+------------------------+\r
1056 | **internal\_version**          | 0                      |\r
1057 +--------------------------------+------------------------+\r
1058 | **creation\_date**             | 2016-11-17 10:10:18    |\r
1059 +--------------------------------+------------------------+\r
1060 | **artifact\_name**             | Scp-template.yml       |\r
1061 +--------------------------------+------------------------+\r
1062 | **artifact\_content**          | <Content>              |\r
1063 +--------------------------------+------------------------+\r
1064 \r
1065 Sequence Generator API\r
1066 ======================\r
1067 \r
1068 The Sequence Generator API generates the steps of execution for LCM\r
1069 operations at minute-level. This API is exposed using the following\r
1070 two endpoints:\r
1071 \r
1072 -  DG plug-in\r
1073 \r
1074 -  REST API\r
1075 \r
1076 The Sequence Generator API takes an input file in JSON format and,\r
1077 based on the parameters defined in the input file, generates an\r
1078 output file.\r
1079 \r
1080 This chapter comprises the following topics:\r
1081 \r
1082 -  Sample input file\r
1083 \r
1084 -  Sample output file\r
1085 \r
1086 -  Supported actions\r
1087 \r
1088     The input file comprises:\r
1089 \r
1090 -  Request information\r
1091 \r
1092 -  Inventory information\r
1093 \r
1094 All these sections of the input file and the parameters used are\r
1095 explained in the subsequent sections.\r
1096 \r
1097 Sample Input File\r
1098 -----------------\r
1099 \r
1100 ::\r
1101 \r
1102         {\r
1103           "request-info": {\r
1104                 "action": "Stop",\r
1105                 "action-level": "vm",\r
1106                 "action-identifier": {\r
1107                   "vnf-id": "abc"\r
1108                 },\r
1109                 "payload":  " {\"vnf-host-ip-address\": \"10.147.124.163\" }"\r
1110           },\r
1111           "inventory-info": {\r
1112                 "vnf-info": {\r
1113                   "vnf-id" : "abc",\r
1114                   "vnf-name": "vSCP",\r
1115                   "vnf-type": "vSCP",\r
1116                   "vnf-version" : "1.0",\r
1117                   "vm": [\r
1118                         {\r
1119                           "vserver-id" : "be_vserverid1",\r
1120                           "vnfc":\r
1121                           {\r
1122                                 "vnfc-type": "BE",\r
1123                                 "vnfc-name": "BE - Name"\r
1124                           }\r
1125                         },\r
1126                         {\r
1127                           "vserver-id" : "fe_vserverid1",\r
1128                           "vnfc":\r
1129                           {\r
1130                                 "vnfc-type": "FE",\r
1131                                 "vnfc-name": "FE - Name"\r
1132                           }\r
1133                         },\r
1134                         {\r
1135                           "vserver-id" : "smp_vserverid1",\r
1136                           "vnfc":\r
1137                           {\r
1138                                 "vnfc-type": "SMP",\r
1139                                 "vnfc-name": "SMP - Name"\r
1140                           }\r
1141                         }\r
1142                   ]\r
1143                 }\r
1144           }\r
1145         }\r
1146 \r
1147 \r
1148 Parameters\r
1149 ~~~~~~~~~~\r
1150 \r
1151 This section explains the parameters used in the Sequence Generator\r
1152 API input file.\r
1153 \r
1154 +-----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------+-----------------+\r
1155 | **Parameter name**          | **Description**                                                                                                                                                               | **Possible values**                   | **Required?**   |\r
1156 +=============================+===============================================================================================================================================================================+=======================================+=================+\r
1157 | **Request Information**                                                                                                                                                                                                                                               |\r
1158 +-----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------+-----------------+\r
1159 | action                      | The action to be executed by Sequence Generator API.                                                                                                                          | Start,Stop                            | Y               |\r
1160 +-----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------+-----------------+\r
1161 | action-level                | Represents the level for the action such as, vm, vnfc.                                                                                                                        | Vnf,vnfc,vm,vf-module                 | Y               |\r
1162 +-----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------+-----------------+\r
1163 | 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
1164 +-----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------+-----------------+\r
1165 | vnf-id                      | Identifies the VNF instance to which this action is to be applied. vnf-id uniquely identifies the service-instance.                                                           | String                                | N               |\r
1166 +-----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------+-----------------+\r
1167 | payload                     | An action-specific open-format field. The payload can be any valid JSON string value.                                                                                         | AICIdentity and vnf-host-ip-address   | N               |\r
1168 +-----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------+-----------------+\r
1169 | **Inventory Information**                                                                                                                                                                                                                                             |\r
1170 +-----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------+-----------------+\r
1171 | vnfInfo                     | Represents the VNF information to which this action is to be applied.                                                                                                         | String                                | Y               |\r
1172 +-----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------+-----------------+\r
1173 | vnf-id                      | Identifies the VNF instance to which this action is to be applied. vnf-id uniquely identifies the service-instance.                                                           | String                                | N               |\r
1174 +-----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------+-----------------+\r
1175 | vnf-name                    | Identifies the VNF instance to which this action is to be applied.                                                                                                            | vSCP                                  | N               |\r
1176 +-----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------+-----------------+\r
1177 | vnf-type                    | Represents the type of the VNF instance.                                                                                                                                      | vSCP                                  | N               |\r
1178 +-----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------+-----------------+\r
1179 | vnf-version                 | Represents the version of the VNF instance.                                                                                                                                   | Alphanumeric                          | N               |\r
1180 +-----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------+-----------------+\r
1181 | vm                          | Represents the VM information to which this action is to be applied.                                                                                                          | List of VMs                           | Y               |\r
1182 +-----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------+-----------------+\r
1183 | vserver-id                  | Identifies a specific VM instance to which this action is to be applied.                                                                                                      | Alpha-numeric unique ID               | Y               |\r
1184 +-----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------+-----------------+\r
1185 | vnfc                        | Represents the VNFC information to which this action is to be applied.                                                                                                        | vnfc-type, vnfc-name                  | N               |\r
1186 +-----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------+-----------------+\r
1187 | vnfc-type                   | Represents the type of the VNFC instance.                                                                                                                                     | FE,BE,SMP                             | N               |\r
1188 +-----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------+-----------------+\r
1189 | vnfc-name                   | Identifies the VNFC instance to which this action is to be applied.                                                                                                           | FE-Name, BE-Name, SMP-Name            | N               |\r
1190 +-----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------+-----------------+\r
1191 \r
1192 Sample Output file\r
1193 ------------------\r
1194 \r
1195 ::\r
1196 \r
1197         [{\r
1198                 "transactionId": 1,\r
1199                 "action": "Stop",\r
1200                 "action-level": "vm",\r
1201                 "action-identifier": {\r
1202                         "vserver-id": "be_vserverid1"\r
1203                 },\r
1204                 "payload": " {\"vnf-host-ip-address\": \"10.147.124.163\" }",\r
1205                 "responses": [{\r
1206                         "response-message": "failure",\r
1207                         "response-action": {\r
1208                                 "ignore": "true"\r
1209                         }\r
1210                 }]\r
1211         },\r
1212         {\r
1213                 "transactionId": 2,\r
1214                 "action": "Stop",\r
1215                 "action-level": "vm",\r
1216                 "action-identifier": {\r
1217                         "vserver-id": "fe_vserverid1"\r
1218                 },\r
1219                 "payload": " {\"vnf-host-ip-address\": \"10.147.124.163\" }",\r
1220                 "responses": [{\r
1221                         "response-message": "failure",\r
1222                         "response-action": {\r
1223                                 "ignore": "true"\r
1224                         }\r
1225                 }]\r
1226         },\r
1227         {\r
1228                 "transactionId": 3,\r
1229                 "action": "Stop",\r
1230                 "action-level": "vm",\r
1231                 "action-identifier": {\r
1232                         "vserver-id": "smp_vserverid1"\r
1233                 },\r
1234                 "payload": " {\"vnf-host-ip-address\": \"10.147.124.163\" }",\r
1235                 "responses": [{\r
1236                         "response-message": "failure",\r
1237                         "response-action": {\r
1238                                 "ignore": "true"\r
1239                         }\r
1240                 }]\r
1241         }\r
1242         ]\r
1243 \r
1244 \r
1245 Supported Actions\r
1246 -----------------\r
1247 \r
1248 The following actions are supported for the Sequence Generator API\r
1249 for the Amsterdam release:\r
1250 \r
1251 -  Generate Runtime Sequence Flow for Start Action with no dependency\r
1252    model\r
1253 \r
1254 -  Generate Runtime Sequence Flow for Stop Action with no dependency\r
1255    model\r
1256 \r
1257 .. |image0| image:: media/AppCDeployment.png\r
1258    :width: 6.50000in\r
1259    :height: 2.55903in\r
1260 .. |image1| image:: media/AppCApidoxExplorer.png\r
1261    :width: 6.50000in\r
1262    :height: 4.83611in\r
1263 .. |image2| image:: media/AppCApidoxExplorer2.png\r
1264    :width: 6.50000in\r
1265    :height: 5.50139in\r
1266 .. |image3| image:: media/AppCApidoxExplorer3.png\r
1267    :width: 6.50000in\r
1268    :height: 5.65347in\r
1269 .. |image4| image:: media/AppCApidoxExplorer4.png\r
1270    :width: 6.50000in\r
1271    :height: 6.62292in\r
1272 .. |image5| image:: media/AppCArchitectureDiagram.png\r
1273    :width: 6.50000in\r
1274    :height: 3.40347in\r
1275 .. |image6| image:: media/AppCDGOrchestratorArchitecture.png\r
1276    :width: 6.36597in\r
1277    :height: 3.72903in\r