Mulitple standalone ansible servers support

In ONAP community, using ansible server to configure VNF is more popular now. As of Casablanca release, APPC has provided one single ansible server configuration functionality. In Dublin, APPC will allow multiple ansible server end points for routing life cycle command (see LCM API for more details). In order to support this new function. APPC will be enhancing in several adapators, database as well as CDT GUI. This page describes how to implement, how to use this feature, and some sample requests/response will be shown.

Design

Currently APP-C directs Life Cycle commands to one and only one ansible server. This feature will enhance APPC to allow multiple ansible server end points to be defined within APPC. This will allow APP-C to route life cycle commands to additional Ansible servers (active-active).

Database enhancement:

A new table will be added for storing admin artifact:

Asdc_artifacts_id <next_serial_number>
Artifact_type <APPC-CONFIG>
Artifact_version <0.1>
Artifact_description <VNF Management Admin Artifact>
Internal_version <start with 0 and increment upon new verion>
Creation_date <system date and time>
Artifact_name <ansible_admin_FQDN_Artifact_0.0.1V.json>
Artifact_content <actual json refer to the sample below>

CDT will keep using the Design interface to retrieve and save Admin Artifact to the new table above. Admin artifact is VNF and action agnostic. Those attributes will have a null value as inputs of the API calls.

User ID = “admin”
Vnf-type = null
Action = null

/operations/design-services:dbservice

Sample Request to Save

{
  "input": {
    "design-request": {
      "request-id":"704632839946",
      "action": "uploadArtifact",
      "payload":
          "{\"userID\": \"admin\",\"vnf-type\" : \"NULL
            \",\"action\" : \"NULL\",\"artifact-name\" :
            \"reference_AllAction_vnfc2_0.0.1V.json\",\"artifact-type\"
            : \"APPC-CONFIG\",\"artifact-version\" :
           \"0.1\",\"artifact-contents\": "<content>”
    }
  }
}

Sample request to retrieve:

{
  "input": {
    "design-request": {
      "request-id": "704632839946",
      "action": "getArtifact",
      "payload": 
          "{\"vnf-type\":\"NULL\",\"vnfc-type\":\"null\",\"protocol\":\"\",\"incart\":\"N\",\"action\":\"NULL
            \",\"artifact-name\":\"reference_AllAction_vnfc2_0.0.1V.json\",\"artifact-type\":\"APPC-CONFIG\",\"userID\":\"admin\"}"
    }
  }
}

CDT GUI enhancement:

The following table lists screen objects is for the CDT GUI.

Data Fields	Required	Data Type	Field Size	Description
Configuration Server FQDN	Yes	String		FQDN of the Ansible server
Configuration Server Port	Yes	Integer	0 – 65535 inclusive	TCP Port of the Ansible server
Cloud-owner	Yes	String		Cloud-owner of the tenant ID
Cloud-Region-ID	Yes	String		Cloud-Region of the tenant ID
Tenant	Yes	String		Tenant ID that is associated with the Ansible server. Cloud-Owner, Cloud-Region, and Tenant ID uniquely identify a tenant. There should be at least one Tenant ID per Ansible server profile.
Description	No	String		This a free text field for entering information identifying the Ansible server.
Creator	Yes	String		Current session user ID for created the profile, source from cookie. Not user editable.
Date Created	Yes	Date		Source from system clock at time of save artifact. Not user editable.
Modifier	Required only when modifying an existing profile	String		Will not be populated when profile initially created. Required when modifying existing profile. Not user editable.
Date Modified	Required only when modifying an existing profile	Date

(screen shot will come lately)

CDT GUI will have a new tab – “ADMIN” tab for administering configuration server profiles.

ADMIN main screen displays configuration server profiles. All (Admin) users have read and write access to all server profiles. User can select columns to be sorted. All columns are sortable.

Runtime enhancement:

Payload example:

Ref link:

Ansible Playbook Examples in VNF Guide.
Ansible Adaptor in APPC