diff options
| -rw-r--r-- | docs/Chapter7.rst | 62 | ||||
| -rw-r--r-- | docs/Chapter8.rst | 210 |
2 files changed, 11 insertions, 261 deletions
diff --git a/docs/Chapter7.rst b/docs/Chapter7.rst index 5128978..943d7df 100644 --- a/docs/Chapter7.rst +++ b/docs/Chapter7.rst @@ -181,7 +181,7 @@ industry standards. * R-62468 The VNF **MUST** allow all configuration data shall to be edited through a NETCONF <edit-config> operation. Proprietary NETCONF RPCs that make configuration changes are not sufficient. * R-01382 The VNF **MUST** allow the entire configuration of the VNF to be retrieved via NETCONF's <get-config> and <edit-config>, independently of whether it was configured via NETCONF or other mechanisms. * R-28756 The VNF **MUST** support **:partial-lock** and **:partial-unlock** capabilities, defined in RFC 5717. This allows multiple independent clients to each write to a different part of the <running> configuration at the same time. -* R-83873 The VNF **MUST** support **:rollback-on-error** value for the <error-option> parameter to the <edit-config> operation. If any error occurs during the requested edit operation, then the target database (usually the running configuration) will be left affected. This provides an 'all-or-nothing' edit mode for a single <edit-config> request. +* R-83873 The VNF **MUST** support **:rollback-on-error** value for the <error-option> parameter to the <edit-config> operation. If any error occurs during the requested edit operation, then the target database (usually the running configuration) will be left unaffected. This provides an 'all-or-nothing' edit mode for a single <edit-config> request. * R-68990 The VNF **MUST** support the **:startup** capability. It will allow the running configuration to be copied to this special database. It can also be locked and unlocked. * R-68200 The VNF **MUST** support the **:url** value to specify protocol operation source and target parameters. The capability URI for this feature will indicate which schemes (e.g., file, https, sftp) that the server supports within a particular URL value. The 'file' scheme allows for editable local configuration databases. The other schemes allow for remote storage of configuration databases. * R-20353 The VNF **MUST** implement at least one of the capabilities **:candidate** or **:writable-running**. If both **:candidate** and **:writable-running** are provided then two locks should be supported. @@ -328,19 +328,6 @@ Chef-Client and Push Jobs Client on the VNF **VNF Configuration via Chef Requirements** -**Chef Server Requirements** - -ONAP will interact with the Chef Server designated to manage a target VNF. ONAP design allows for the VNF to register with the following types of Chef Server [2]_: - -- **Chef Server hosted by ONAP**: ONAP will provide a Chef Server to manage a VNF. - - * R-77786 The VNF Package **MUST** include all relevant cookbooks to be loaded on the ONAP Chef Server. - -- **Chef Server hosted in Tenant Space**: The Chef Server may also be hosted external to ONAP in tenant space. - - * R-85428 The VNF **MUST** meet the same guidelines as Chef Server hosted by ONAP. - * R-23823 The VNF Package **MUST** include appropriate credentials so that ONAP can interact with the Chef Server. - **Chef Client Requirements** * R-79224 The VNF **MUST** have the chef-client be preloaded with validator keys and configuration to register with the designated Chef Server as part of the installation process. @@ -390,7 +377,7 @@ action request against a Chef managed VNF. 3. Next, it creates a Node Object from the “Node” JSON dictionary for all elements listed in the NodeList (using the FQDN to construct the - endpoint) by replicating it [3]_. As part of this process, it will + endpoint) by replicating it [2]_. As part of this process, it will set the name field in each Node Object to the corresponding FQDN. These node objects are then posted on the Chef Server to corresponding Node Object REST endpoints to update the corresponding @@ -445,23 +432,9 @@ manage VNFs that support Ansible. **VNF Configuration via Ansible Requirements** -**Ansible Server Requirements** - -ONAP will utilize an Ansible server in order to manage VNFs that support Ansible playbooks. We note that Ansible in general does not require the use of a server. However, this framework has been adopted to align with ONAP architecture, ease of management and scalability. -All playbooks for the VNF will be hosted on a designated Ansible Server that meets ONAP Ansible API requirements. ONAP design allows for VNFs to be managed by an Ansible Server in any of the two following forms [4]_: - -- **Ansible Server hosted by ONAP**: ONAP will provide an Ansible Server to manage a VNF. - - * R-07879 The VNF Package **MUST** include all relevant playbooks to ONAP to be loaded on the Ansible Server. - -- **Ansible Server hosted in Tenant Space**: - - * R-35305 The VNF **MUST** meet the same guidelines as the Ansible Server hosted by ONAP. - * R-91681 The VNF **MUST** meet the ONAP Ansible Server API Interface requirements. - **Ansible Client Requirements** -* R-32217 The VNF **MUST** have routable FQDNs that are reachable via the Ansible Server for the endpoints (VMs) of a VNF on which playbooks will be executed. ONAP will initiate requests to the Ansible Server for invocation of playbooks against these end points [5]_. +* R-32217 The VNF **MUST** have routable FQDNs that are reachable via the Ansible Server for the endpoints (VMs) of a VNF on which playbooks will be executed. ONAP will initiate requests to the Ansible Server for invocation of playbooks against these end points [3]_. * R-98929 The VNF **MAY** have a single endpoint. * R-54373 The VNF **MUST** have Python >= 2.7 on the endpoint VM(s) of a VNF on which an Ansible playbook will be executed. * R-35401 The VNF **MUST** must support SSH and allow SSH access to the Ansible server for the endpoint VM(s) and comply with the Network Cloud Service Provider guidelines for authentication and access. @@ -471,7 +444,7 @@ All playbooks for the VNF will be hosted on a designated Ansible Server that mee An Ansible playbook is a collection of tasks that is executed on the Ansible server (local host) and/or the target VM (s) in order to complete the desired action. * R-40293 The VNF **MUST** make available (or load on VNF Ansible Server) playbooks that conform to the ONAP requirement. -* R-49396 The VNF **MUST** support each VNF action by invocation of **one** playbook [6]_. The playbook will be responsible for executing all necessary tasks (as well as calling other playbooks) to complete the request. +* R-49396 The VNF **MUST** support each VNF action by invocation of **one** playbook [4]_. The playbook will be responsible for executing all necessary tasks (as well as calling other playbooks) to complete the request. * R-33280 The VNF **MUST NOT** use any instance specific parameters in a playbook. * R-48698 The VNF **MUST** utilize information from key value pairs that will be provided by the Ansible Server as extra-vars during invocation to execute the desired VNF action. If the playbook requires files, they must also be supplied using the methodology detailed in the Ansible Server API. @@ -658,7 +631,7 @@ Monitoring & Management Requirements **Encoding and Serialization** -* R-19624 The VNF **MUST** encode and serialize content delivered to ONAP using JSON (option 1). High-volume data is to be encoded and serialized using Avro, where Avro data format are described using JSON (option 2) [7]_. +* R-19624 The VNF **MUST** encode and serialize content delivered to ONAP using JSON (option 1). High-volume data is to be encoded and serialized using Avro, where Avro data format are described using JSON (option 2) [5]_. - JSON plain text format is preferred for moderate volume data sets (option 1), as JSON has the advantage of having well-understood simple processing and being human-readable without additional decoding. Examples of moderate volume data sets include the fault alarms and performance alerts, heartbeat messages, measurements used for VNF scaling and syslogs. - Binary format using Avro is preferred for high volume data sets (option 2) such as mobility flow measurements and other high-volume streaming events (such as mobility signaling events or SIP signaling) or bulk data, as this will significantly reduce the volume of data to be transmitted. As of the date of this document, all events are reported using plain text JSON and REST. @@ -716,7 +689,7 @@ runtime lifecycle. This data model is referred to as the VNF Event Streaming (VES) specifications. While this document is focused on specifying some of the records from the ONAP perspective, there may be other external bodies using the same framework to specify additional -records. For example, OPNFV has a VES project [8]_ that is looking to +records. For example, OPNFV has a VES project [6]_ that is looking to specify records for OpenStack’s internal telemetry to manage Application (VNFs), physical and virtual infrastructure (compute, storage, network devices), and virtual infrastructure managers (cloud controllers, SDN @@ -890,36 +863,21 @@ Listener <https://github.com/att/evel-test-collector/tree/master/docs/att_interf https://github.com/mbj4668/pyang .. [2] - Decision on which Chef Server instance associates with a VNF will be - made on a case-by-case basis depending on VNF, access requirements, - etc. and are outside the scope of this document. The specific - criteria for this would involve considerations like connectivity and - access required by the VNF, security, VNF topology and proprietary - cookbooks. - -.. [3] Recall that the Node Object **is required** to be identical across all VMs of a VNF invoked as part of the action except for the “name”. -.. [4] - Decision on which Ansible Server to use may happen on a case-by-case - basis depending on VNF, access requirements etc. and are outside the - scope of this document. The specific criteria for this could involve - considerations like connectivity and access required by the VNF, - security, VNF topology and proprietary playbooks. - -.. [5] +.. [3] Upstream elements must provide the appropriate FQDN in the request to ONAP for the desired action. -.. [6] +.. [4] Multiple ONAP actions may map to one playbook. -.. [7] +.. [5] This option is not currently supported in ONAP and it is currently under consideration. -.. [8] +.. [6] https://wiki.opnfv.org/display/PROJ/VNF+Event+Stream .. |image0| image:: Data_Model_For_Event_Records.png diff --git a/docs/Chapter8.rst b/docs/Chapter8.rst index eeb2b0c..4ce9895 100644 --- a/docs/Chapter8.rst +++ b/docs/Chapter8.rst @@ -548,215 +548,7 @@ Table C8. Required Fields for Amount | Type of User | Describes the types of users of the functionality offered by the software (e.g., authorized, named). This field is included when Limit Type is user. | String | Optional | +------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------+-------------+ - -d. – Ansible Server Specification -============================================= - -This section outlines the specifications for an ONAP compliant Ansible -Server that can optionally be provided by the VNF Vendor. The Ansible -Server will be used as a repository to store Ansible playbooks as well -as an execution engine which upon a REST API request, will execute -Ansible playbook against VNFs. - -Table D1. Ansible Server Requirements -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -+----------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+ -| **Principle** | **Description** | **Type** | **ID #** | -+==============================================+==============================================================================================================================================================================================================================================================================================================================================================================+============+============+ -| Ansible Server Scope | The Ansible Server is required to support storage and execution of playbooks that are in yaml format or a collection of playbooks compressed and uploaded in tar-ball format. | Must | D1000 | -+----------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+ -| | The Ansible Server must accept requests for execution of playbooks via a REST interface. The scope of each request will involve exactly one action and will request execution of one playbook. | Must | D1010 | -+----------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+ -| | The playbook executed by the Ansible Server will be responsible for execution of the entire action against the VNF (e.g., calling other playbooks, running tasks on multiple VMs in the VNF) and return back the status of the action as well as any necessary output in its entirety after the action is finished. | Must | D1020 | -+----------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+ -| | The Ansible Server must support simultaneous execution of multiple playbooks against different VNFs in parallel (i.e., process multiple requests). | Must | D1030 | -+----------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+ -| | The Ansible Server will be loaded with all necessary credentials to invoke playbooks against target VNF(s). | Must | D1040 | -+----------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+ -| Ansible Server/ONAP Interface | Load Playbook\ **:** The Ansible Server must expose an authenticated interface to allow loading all necessary playbooks for a target VNF. It should impose an identification mechanism that allows each playbook to be uniquely identified. | Must | D1050 | -| | | | | -| | - It is recommended that the load Playbook API be a REST API. | | | -+----------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+ -| | Request API: The Ansible Server must expose a REST endpoint that accepts a POST message to request execution of the playbook. The POST request must be a JSON block as outlined in Table D2. | Must | D1060 | -+----------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+ -| | When the Ansible server accepts an authenticated request to execute a playbook, it is required to send back an initial response indicating whether the request is accepted or rejected. The response must be a JSON Object with the key value pairs as described in Table D3. | Must | D1070 | -+----------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+ -| | Result API: If the Ansible Server accepts a request to execute a playbook, it must make available status of the execution of the playbook at a Results REST endpoint indexed by the Id in the request in the form <url>?Id=<RequestId>&Type=GetResult where <url> is the URL used for submitting requests. | Must | D1080 | -+----------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+ -| | When a GET is invoked against the Results REST endpoint, the Ansible Server must reply with an appropriate response: | Must | D1090 | -| | | | | -| | - If the Endpoint is invalid (no request, or request expired), reply with a standard HTTP 404 error. | | | -| | | | | -| | - If the playbook execution is still ongoing, then the Ansible Server is required to block on the GET request till the execution finishes or terminates. | | | -| | | | | -| | - Upon completion of execution, the Ansible Server is required to respond to the GET request with the result of the playbook execution in the form of a JSON message as outlined in the Table D4. | | | -+----------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+ -| | The dictionary associated with the ‘Results’ key in the Result Response must be a key-value pair where each key corresponds to an entry in the NodeList and the value is a dictionary with the format as outlined in Table D5. | Must | D1100 | -+----------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+ -| Ansible Server Actions | The Ansible Server must take the following actions when triggered by a request to execute a playbook: | Must | D1110 | -| | | | | -| | - Determine if the request is valid, and if so, must send back an initial response message accepting the request. | | | -| | | | | -| | - If the request contains a “FileParameters” key that is not NULL, create all the necessary files. | | | -| | | | | -| | - Invoke the ansible playbook while providing it all appropriate parameters listed in EnvParameters and inventory information listed in NodeList. The playbook will be responsible for execution of all necessary steps required by the VNF action. | | | -| | | | | -| | - If the playbook finishes, use the PLAY\_RECAP functionality to determine whether playbook finished successfully on each endpoint identified in the NodeList. | | | -| | | | | -| | - If the playbook finishes, collect any output returned by the playbook. A playbook conforming to the ONAP vendor requirements document will write out any necessary output to a file named ‘<hostname>\_results.txt’ in the working directory, where ‘hostname’ is an element of the NodeList where the playbook is being executed. | | | -| | | | | -| | - If the playbook execution exceeds the Timeout value, the playbook execution process is terminated and ansible log that captures the last task executed is stored. | | | -| | | | | -| | - Make results available on the Results REST Endpoint as documented in Table D3. | | | -| | | | | -| | - If Callback url was provided in initial request, post the final response message on the Callback URL along with an additional key additional key “Id “: which corresponds to the request Id sent in the request. | | | -+----------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+ -| Ansible Server Result Storage Requirements | The Ansible Server must cache and provide results of an execution as well as retain logs for debugging purposes as outlined below: | Must | D1120 | -| | | | | -| | - The results from a playbook execution result must be retained by the Ansible Server and made available through the respective REST endpoint for a duration that is configurable. | | | -| | | | | -| | - Recommended duration is 2 x Timeout. | | | -| | | | | -| | - The log from a playbook must be stored by the Ansible Server, tagged with the Id along with all other parameters in the initial request in a format that allows for examination for debugging purposes. | | | -| | | | | -| | - The results from playbook execution and log files shall be removed after a configurable defined retention period for this type of file. | | | -+----------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+ -| Ansible Server Locking Mechanism | The Ansible Server shall lock VNF while running playbooks that require exclusive use of a VNF (Configure is an example) and not accept requests to run other playbooks or queue those requests until playbook that requires exclusivity completes | Must | D1130 | -+----------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+ - -Table D2. Request Message -~~~~~~~~~~~~~~~~~~~~~~~~~ - -+-------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------+------------------------------------------------------------------------------------------------------------------------------------+ -| **Key** | **Description** | **Type** | **Comment** | -+===================+=========================================================================================================================================================================================================================================================================================================================================================+=============+====================================================================================================================================+ -| Id | A unique string that identifies this request. For e.g., a UUID | Mandatory | NOT NULL | -+-------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------+------------------------------------------------------------------------------------------------------------------------------------+ -| PlaybookName | A string which contains the name of the playbook to execute. | Mandatory | NOT NULL | -| | | | | -| | Example: memthres.yaml | | | -+-------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------+------------------------------------------------------------------------------------------------------------------------------------+ -| Action | Name of action | Optional | | -+-------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------+------------------------------------------------------------------------------------------------------------------------------------+ -| NodeList | List of endpoints of the VNF against which the playbook should be executed. | Optional | If not specified, playbook executed within Ansible Server (localhost) | -+-------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------+------------------------------------------------------------------------------------------------------------------------------------+ -| Timeout | Time the Ansible Server should wait (in seconds), before terminating playbook execution. The Ansible Server will apply the timeout for the entire playbook execution (i.e., independent of number of endpoints against which the playbook is executing). If playbook execution time exceeds the timeout value, the server will terminate the process. | Optional | If not specified, Ansible server will use internal default value (configurable) | -+-------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------+------------------------------------------------------------------------------------------------------------------------------------+ -| LocalParameters | A JSON dictionary that can be used to provide key value pairs that are specific to each individual VNF/VM instance. Key must be endpoint FQDN and value a JSON dictionary with key-value pairs for the playbook run associated with that host/group. | Optional | | -+-------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------+------------------------------------------------------------------------------------------------------------------------------------+ -| EnvParameters | A JSON dictionary that can be used to specify key value pairs passed at run time to the playbook that are common across all hosts against which the playbook will run. | Optional | | -+-------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------+------------------------------------------------------------------------------------------------------------------------------------+ -| CallbackUrl | A callback URL that Ansible Server can POST results to once playbook finishes execution or is terminated. | Optional | If present, Ansible Server is required to POST response back on the Callback URL | -+-------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------+------------------------------------------------------------------------------------------------------------------------------------+ -| FileParameters | A dictionary where keys correspond to file names to be generated and values correspond to contents of files. | Optional | If present, Ansible Server will first process this and write out contents to appropriate files and then process other parameters | -+-------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------+------------------------------------------------------------------------------------------------------------------------------------+ - -Table D3. Initial Response Message -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -+--------------------+------------------------------------------------------------------------------------------+-------------+---------------+ -| **Key** | **Description** | **Type** | **Comment** | -+====================+==========================================================================================+=============+===============+ -| StatusCode | An integer indicating status of the request. It MUST take one of the following values: | Mandatory | | -| | | | | -| | 100 if request is accepted | | | -| | | | | -| | 101 if request is rejected | | | -+--------------------+------------------------------------------------------------------------------------------+-------------+---------------+ -| StatusMessage | A string describing Server’s response | Mandatory | | -| | | | | -| | It MUST be set to ‘PENDING’ if StatusCode=100 | | | -| | | | | -| | It MUST be set to appropriate error exception message if StatusCode=101 | | | -+--------------------+------------------------------------------------------------------------------------------+-------------+---------------+ -| ExpectedDuration | Time the server expects (in seconds) to finish the playbook execution. | Optional | | -+--------------------+------------------------------------------------------------------------------------------+-------------+---------------+ - -Table D4. Final Response Message -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -+-----------------+-------------------------------------------------------------------------------------------------------+-------------+------------------------+ -| **Key** | **Description** | **Type** | **Comment** | -+=================+=======================================================================================================+=============+========================+ -| StatusCode | 200 if Execution finished normally | Mandatory | | -| | | | | -| | 500 otherwise. | | | -+-----------------+-------------------------------------------------------------------------------------------------------+-------------+------------------------+ -| StatusMessage | A string which be set to either of the TWO values: | Mandatory | | -| | | | | -| | - ‘FINISHED’ if StatusCode=200 | | | -| | | | | -| | - Appropriate error exception message if StatusCode=500 | | | -+-----------------+-------------------------------------------------------------------------------------------------------+-------------+------------------------+ -| Duration | Time it took for execution to finish (in seconds). | Optional | | -+-----------------+-------------------------------------------------------------------------------------------------------+-------------+------------------------+ -| Result | A JSON dictionary that lists the status of playbook execution for each VM (or VNF) in the NodeList. | Optional | Not present if empty | -+-----------------+-------------------------------------------------------------------------------------------------------+-------------+------------------------+ - -Table D5. Result Block Format -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -+-----------------+----------------------------------------------------------+-------------+------------------------+ -| **Key** | **Description** | **Type** | **Comment** | -+=================+==========================================================+=============+========================+ -| GroupName | Group under which the VM (or VNF) falls in a playbook. | Optional | | -+-----------------+----------------------------------------------------------+-------------+------------------------+ -| StatusCode | A string which must have the following values: | Mandatory | | -| | | | | -| | - 200 if SUCCESS | | | -| | | | | -| | - 500 otherwise | | | -+-----------------+----------------------------------------------------------+-------------+------------------------+ -| StatusMessage | An integer with the following values: | Mandatory | | -| | | | | -| | - ‘SUCCESS’ if StatusCode=200 | | | -| | | | | -| | - Error exception message otherwise | | | -+-----------------+----------------------------------------------------------+-------------+------------------------+ -| Output | Any output the playbook is required to return. | Optional | Not present if empty | -+-----------------+----------------------------------------------------------+-------------+------------------------+ - -Some illustrative examples are shown below: - -1. An example POST for requesting execution of a Playbook : - - {"Id": "10", “Action”:”HealthCheck”, "PlaybookName": - "ansible\_getresource.yml", "NodeList": - ["interface1.vnf\_b.onap.com", ["interface2.vnf\_b.onap.com"], - "Timeout": 60, "EnvParameters": {"Retry": 3, "Wait": 5}} - -2. Potential examples of Ansible Server initial response. - - a. Successfully accepted request: {"StatusCode": "100", - "ExpectedDuration": "60sec", "StatusMessage": "PENDING"} - - b. Request rejected: {"StatusCode": "101", "StatusMessage": "PLAYBOOK - NOT FOUND "} - -3. Potential examples of final response by Ansible Server to a GET on - - a. Playbook successful execution: {"Duration": "4.864815sec", - “StatusCode”: 200, “StatusMessage”:”FINISHED”, "Results": - {"interface\_1.vnf\_b.onap.com": {"StatusCode": "200", - "GroupName": "vnf-x-oam", "StatusMessage": "SUCCESS", - “Output”:{“CPU”:30, “Memory”:”5Gb”}, - "interface\_1.vnf\_b.onap.com": {"StatusCode": "200", "GroupName": - "vnf-x-oam", "StatusMessage": "SUCCESS", “Output”:{“CPU”:60, - “Memory”:”10Gb”}}} - - b. Playbook failed execution on one of the hosts: {"Duration": - "10.8sec", “StatusCode”: 200, “StatusMessage”:”FINISHED”, - "Results": {"interface\_1.vnf\_b.onap.com": {"StatusCode": "500", - "GroupName": "vnf-x-oam", "StatusMessage": "Error executing - command ", "interface\_1.vnf\_b.onap.com": {"StatusCode": "200", - "GroupName": "vnf-x-oam", "StatusMessage": "SUCCESS", - “Output”:{“CPU”:60, “Memory”:”10Gb”}}} - - c. Playbook terminated: {"Duration": "61 sec", “StatusCode”: 500, - “StatusMessage”:”TERMINATED” } - -e. – Requirement List +d. – Requirement List ================================== R-11200: The VNF MUST keep the scope of a Cinder volume module, when it exists, to be 1:1 with the VNF Base Module or Incremental Module. |