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