This wiki provides documentation regarding the design, capabilities and
usage of the Ansible Extension for APP-C. Ansible is a an open-source
VNF management framework that allows provide an almost cli like set of
tools in a structured form. It is agentless in that the target VNF need
not have any additional software other than:

SSH server

Python >= 2.7

Any necessary software that is specific to the VNF to run its functions.

Any action (e.g configure, restart, health check etc) can be
executed on the VNF by constructing a playbook (or set of playbooks)
that is executed by an Ansible agent on the VNF via SSH.

The Ansible Extension for APP-C allows management of VNFs that support Ansible
through the following three additions :

An APP-C/Ansible Server interface: Ansible libraries are written in python and hence cannot be executed natively from within the APP-C Karaf container. Instead, the design calls for an Ansible Server that can execute the Ansible playbooks and exposes a REST interface that is compliant with requirements of APP-C. These requirements are documented as the Server API Interface that any compliant Ansible Server must support. Exact implementation of the Ansible Server is left open and does not affect APP-C operations as long as the server follows the interface. For purposes of evaluation, a reference web server that implements this APP-C/Ansible Server interface has been developed and the code is available from the App-C ONAP repository under appc-adapters/appc-ansible-adapter/appc-ansible-example-server.

An APP-C Ansible adapter: The ansible adapter is an OSGI bundle in the APP-C Karaf container that interacts with the Ansible Server . It is essentially a set of REST calls that performs two actions, submit request for a playbook to be executed, and if required get the results of the playbook after execution (if in synchronous mode).

Ansible Directed Graph (DG): The Ansible Directed graph is generic DG that can be used to invoke any playbook via Ansible (and hence any APP-C action, since in Ansible, VNF actions map to playbooks) corresponding to an LCM action.

The architecture design for supporting Ansible is outlined in the diagram below :

The workflow envisioned when Application Controller receives an event is
as follows :

Application Controller receives event from the Event Bus for an LCM action.

The appropriate LCM API invokes the Dispatcher which performs the relevant lookups for A&AI and Workflow (DG information).

Ansible DG leverages the Ansible Adapter to interact with the Ansible Server.

Ansible Server invokes the appropriate playbook which in turn interacts with the VNF and then returns the playbook results.

Ansible Server returns results.

Ansible DG provides these results back to calling DG.

A ladder diagram of the work flow is pasted below :

Details of each of these three (DG, Adapter and Ansible Server) are listed below :

1. Ansible Directed Graph (DG): The Ansible Directed graph is the most common way an App-C developer is expected to leverage Ansible functionality. The Ansible DG is a general purpose graph that can be used to invoke and retrieve results from any playbook on an ONAP-compliant Ansible Server. The Ansible Graph,when called, expects a certain set of inputs to be provided as input and when upon completion provides results from the execution of the Ansible playbook. The Ansible
DG can be invoked using the following (current) naming:

Field

Value

module

APPC

rpc

ansible-adapter-1.0

version

2.0.1

The inputs that the Ansible DG expects in DG context memory are listed below:

Table 1: Input Parameters to the Ansible Directed Graph

Variable Name

Description

Type

Comments

User

Username to logon to Ansible Server

Mandatory

Should be provided by APPC.

Password

Password to logon to Ansible Server

Mandatory

Should be provided by APPC.

AgentUrl

The complete URL of the Ansible Server to post the request for
execution and retrieve results (if in synchronous mode)

Mandatory

Should be provided by APPC.

PlaybookName

Name/identifier of playbook to run

Mandatory

To be provided in the template.

Action

The type of VNF action being requested

Optional

Provided either by APPC or Template.

EnvParameters

A JSON dictionary (stringified) listing the parameters to be
passed to the Ansible playbook

Optional

Structure of the EnvParameters dictionary to be supplied in template.
Values to be filled in by App-C based on values from payload in run-time

FileParameters

A JSON dictionary (stringified) listing file names and files to
be created for Ansible playbook

Optional

Structure of the FileParameters dictionary to be supplied in template.
Values to be filled in by App-C based on values from payload in run-time

Timeout

Time Ansible Server should wait before terminating playbook

Optional

To be provided in the template.

NodeList

List of FQDNs/IP Addresses of VNF that the Ansible playbook
should be executed on.

Optional
(if not supplied,
will run on server)

To be provided to App-C during Runtime.

The ‘template’ referred in the above table must be a JSON file as documented in the VNF vendor requirements and must contain the key-value pairs listed above (that are expected to be in the template). An LCM API Directed graph should fill in necessary parameters in the template, and then put the key-value pairs from the template as listed above in DG context memory before calling the Ansible DG.

Upon completion the Ansible DG sets the following variables in DG context memory

Table 2: Output Variables set by Ansible DG Variable

Type

Comments

output.status.code

Result of the request: 400 if SUCCESS , 200 if FAILURE.

The ansible playbook may have multiple sub-tasks, playbooks etc and may
run on multiple VMs of a host. The request is considered to fail if even
one of the tasks is incomplete.

output.status.message

If playbook finished, set to FINISH, if playbook terminated, set to
TERMINATED. If abnormal error, reported in message

output.status.results

A JSON dictionary with results corresponding to output provided by the
Ansible playbook request. This is optional (may not be present if
playbook was terminated). The results, if present, will be in the form
of a dictionary that follows the format presented in the Ansible Server
API Documentation. The document also contains examples of output.

Note : The Ansible Server supports a Callback Url functionality, but it is currently not invoked by App-C Ansible Adapter or Directed Graph. If added, it is easy to change the Adapter and Ansible DG to support this.

APP-C Ansible Adapter: The App-C Ansible Adapter is an OSGI bundle which essentially makes REST calls to the Ansible Server. It exposes three methods that can be invoked by the Service Logic Interpreter (SLI).

void reqExecLog(Map<String, String> params, SvcLogicContext ctx) throws SvcLogicException : A method to retreive the logs from a request (not used in the Ansible DG currently).

Currently, the Ansible DG uses only the first two (reqExec and reqExecResult) since only these two are needed to request execution of a playbook and retrieval of results. The reqExecLog is for diagnostic purposes.

In order to communicate with the Ansible Server, it is currently assumed that:

Credentials comprise of a username and password.

Communication is over https

The Ansible Adapter has three configurable parameters related to SSL certificate of the Ansible Server, which can be set from the properties file:

org.onap.appc.adapter.ansible.clientType. If set to “TRUST_ALL”, will accept all SSL certificates from any Ansible Server. If set to “TRUST_CERT”, will accept SSL from only those Ansible Servers whose certificate is in the trustStore keystore file. These two options can be used for development environment. Default option is to trust only well known server certificates (use in Production).

org.onap.appc.adapter.ansible.trustStore used to point to the keystore file

org.onap.appc.adapter.ansible.trustStorePasswd used to set password for keystore file

The Prototype Ansible Server requires that all credentials and IP Addresses for the VNF being tested either already be present in the Server’s Database or be loaded before any playbooks are invoked. Supported credentials are user-name/password and public-key authentication.

All VNF credentials stored in a unique file (or in a SQL database depending on the ansible server runtime configuration):

Playbooks can either be provided as stand alone text files or gzipped tar file (playbooks with roles sub-directories) either stored in a local file or in an SQL database.

Naming convention: anything_LCM@M.mn.{yml,tar.gz} where version number M is a digit and mn are subversion number digits.

Playbooks should be written such that they can run from the command line: “ansible-playbook -i inventoryfile –extra-vars optionalvariables playbookname” That means the playbook should not contain any VM credentials information, they are expected to be provided through the inventory file passed at run time.

Note: RSA key fingerprint needs to be loaded manually in server for each VM defined in inventory file that requires ssh authentication. This can be done by testing ssh credentials to each target VM and accepting RSA key fingerprint:

Inventory file created at run time, playbook loaded from mysql, both placed in the temporary directory destroyed at end of test (Playbook archive is unpacked in the temporary directory)

All tested playbooks written such that the ansible ‘play recap’ log indicates whether or not the playbook tasks succeeded (multiple tasks in a standalone playbook or playbooks with roles directory structure)