Page Comparison

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 APPC 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 APPC to route life cycle commands to additional Ansible servers (active-active).

Database enhancement

A new table will be added for storing admin artifact:

...

Code Block

language	js
title	Sample of Admin Artifact

{
  "fqdn-list": [
    {
      "vnf-management-server-fqdn": "fqdn-value1 url:port",
      "cloud-owner-list": [
        {
          "cloud-owner": "xxx3.0",
          "region-id-list": [
            {
              "region-id": "san4a",
              "tenant-id-list": [
                "tenantuuid1",
                "tenantuuid2"
              ]
            },
            {
              "region-id": "san4b",
              "tenant-id-list": [
                "tenantuuid1",
                "tenantuuid2"
              ]
            }
          ]
        },
        {
          "cloud-owner": "nc1.0",
          "region-id-list": [
            {
              "region-id": "san4a",
              "tenant-id-list": [
                "tenantuuid3",
                "tenantuuid4"
              ]
            }
          ]
        }
      ],
      "description": "fqdn for east zone vUSP Production",
      "username": "albino attuid",
      "create-date": "",
      "modify-username": "",
      "modify-date": ""
    },
    {
      "vnf-management-server-fqdn": "fqdn-value2 url:port",
      "cloud-owner-list": [
        {
          "cloud-owner": "xxx3.0",
          "region-id-list": [
            {
              "region-id": "san4a",
              "tenant-id-list": [
                "tenantuuid5",
                "tenantuuid6"
              ]
            },
            {
              "region-id": "san4b",
              "tenant-id-list": [
                "tenantuuid5",
                "tenantuuid6"
              ]
            }
          ]
        },
        {
          "cloud-owner": "nc1.0",
          "region-id-list": [
            {
              "region-id": "san4a",
              "tenant-id-list": [
                "tenantuuid7",
                "tenantuuid8"
              ]
            }
          ]
        }
      ],
      "description": "fqdn for east zone vUSP E2E",
      "username": "takacho",
      "create-date": "",
      "modify-username": "",
      "modify-date": ""
    }
  ]
}

CDT GUI enhancement

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

...

new buttons under Admin tab:
- Create New Server button – opens the Server Data screen for adding new server profile
  Clicking the CREATE NEW SERVER button on the default screen takes the user to this Server Data to enter data for a new server profiles.
  These fields are not user editable.
  -          Creator – the user ID when the server profile was first created. Once it is set during initial server profile creation, this value will not be changed.
  -          Date Created – date the server profile was created. Once it is set during initial server profile creation, this value will not be changed.
  -          Modifier – Empty during initial profile creation
  -          Modified Date – Empty during initial profile creation
- View/Edit button – opens the Server Data screen for editing the existing server profile
  The Configuration Server screen allows user to edit existing Ansible profiles. CDT retrieves the server profile data and display on in the appropriate fields.
  These fields are not user editable.
  -          Creator – the user ID when the server profile was first created. Once it is set during initial server profile creation, this value will not be changed.
  -          Date Created – date the server profile was created. Once it is set during initial server profile creation, this value will not be changed.
  -          Modifier – user ID of the server profile was last modified and saved to APPC database.
  -          Modified Date – date of the server profile was last modified and saved to APPC database.
- Download All To PC button – saves the Admin artifact to an file on the local PC
- Save All To APPC button – save Admin artifact to APPC database in JSON format
  Save Admin Artifact in APPC Database
- Arrow symbols next to column heading – sort the data by the specific column

Runtime enhancement

APPC will support saving of the Admin Artifact in the APPC Database – name the artifact as admin artifact.
APPC will provide a script to support the environment specific data in the device authentication table
APPC Runtime will provide enhancement to the authentication util tool for the VNFs with the Ansible protocols to support the maintenance of the user name and password in the device authentication table:
1. Server FQDN <url>
2. Port <port number>
3. User name <for ansible access>
4. Password <for ansible access>
5. VNF type
6. Protocol
7. Action
Validation: For the Ansible Protocol, the Server FQDN/ URL & Port shall be required along with the VNF type, Action, Protocol, User Name and Password.
For the VNF’s with the Ansible protocol, APPC shall allow to store multiple records of a VNF type with different action using 1 FQDN as well as multiple records for a VNF type and its actions using a different FQDN.

...

APPC will enhance the Artifact Handler to support the loading, parsing, processing and saving of the Admin Artifact from CDT:
The Admin artifact from the CDT GUI shall be stored in the DT tables like the other artifacts except that this artifact is VNF agnostic so shall not be associated with a VNF-Type.
The Admin artifact shall also be stored in the ASDC_Artifacts tables like the other artifacts except that this artifact is VNF agnostic so shall not be associated with a VNF-Type.
From the CDT GUI:
"payload": "{\"userID\": \"admin\",\"vnf-type\" : NULL,\"action\" : NULL,\"artifact-name\" : \"ansible_admin_FQDN_Artifact_0.0.1V.json\",\"artifact-type\" : \"APPC-CONFIG\",\"artifact-version\" : \"0.1\",\"artifact-contents\": <content>
APP-C shall will add the records to the DT_Artifacts_tracking tables (in addition to the asdc_artifacts table for the Admin Artifact):

APP-C shall APPC will do enhancement of the Generic Ansible DG orchestrator to support the following for all the LCM actions of the VNFs using the Ansible Protocol.

For all the LCM actions of the VNF’s with the Ansible Protocol, APP-C shall APPC will apply the following steps:

1. From the A&AI queried data for the given VNF retrieve the Tenant ID
  1. In A&AI the generic vnf query:

i. The get query of A&AI has the related vserver with the uri of /cloud-infrastructure/cloud-regions/cloud-region/{cloud-owner}/{cloud-region-id}/tenants/tenant/{tenant-id}/vservers/vserver/{vserver-id}

ii. Extract the cloud-owner, cloud-region-id & thetenant-id from the above URI

iii. Assumptions:

1. 1. 1. 1. APPC is assuming that currently all the vserver objects for a given VNF in A&AI are the same.
      2. APPC is assuming that if the tenant-id by itself may be repeated in different cloud-owner/ cloud-region-id but the cloud-region/ cloud-region-id are unique across all environments and the combination of these 3 attributes will not have an overlap for the mapping with the Ansible server cluster’s FQDN.
2. When the Ansible DG is invoking the logic to read the device authentication it shall apply the following steps:
  1. Using the Cloud-owner, the Cloud-region-id & the Tenant-id from the context memory APP-C shall , APPC will lookup these 3 attributes in the Admin Artifact.

i. If the matching the cloud-owner, cloud-region-id & Tenant-id is found, then

...

APPC will read the vnf-management-server-fqdn

1. 1. 1. 1. Using the VNF-type, Protocol <ANSIBLE>, Action, vnf-management-server-fqdn,
      2. APPC will lookup the record in the device authentication table to find the user name and password.
        If record found from the device authentication table then
      3. APPC shall continue with the POST request to the Ansible Rest API call.
        If record was not found, then
      4. APPC will error out – “Authentication credentials not found for the vnf-management-server-fqdn for the <PROTOCOL> server for the given Tenant - <tenant-id> of the VNF instance <VNF instance name>”

ii. If the matching Tenant-id is not found, then APP-C

...

will error out – “vnf-management-server-fqdn not found for the <PROTOCOL> server for the given Tenant - <tenant-id> of the VNF instance <VNF instance name>”

South bound Ansible Adaptor to read the Ansible FQDN info and connect to the corresponding Ansible server cluster to send the POST request to the Ansible Rest API

APPC will enhance the South bound Ansible Adaptor to read the vnf-management-server-fqdn info and connect to the corresponding Ansible server cluster to send the POST request to the Ansible Rest API.

For all the LCM actions of the VNF’s with the Ansible Protocol, APPC will apply the following steps:

1. 1. South bound Ansible Adaptor to read the vnf-management-server-fqdn info and connect to the corresponding Ansible server cluster to send the POST requests to the Ansible Rest API.
  2. For the given POST request on a VNF, if an IP address is returned by the Ansible Rest API then the Adaptor shall record the IP address and send the get results requests to the given IP address directly.
  3. For the given POST request on a VNF, if an IP address is not returned by the Ansible Rest API then the Adaptor shall send the get results requests as current BAU using the FQDN that was used for the POST request.
  4. All the steps between POST request/ response from APPC to Ansible Rest APIs shall be recorded in the logs.
  5. All the steps between Get Results request/ response from APPC to Ansible Rest APIs shall be recorded in the logs

Sequence in which the FQDN is sourced from Device authentication vs. from the Admin Artifact

APPC will apply sequence in which the FQDN is sourced from Device authentication vs. from the Admin Artifact.

APPC will verify if the device authentication table has only 1 entry for the given VNF type, Protocol, Action.

If yes, then APPC will not invoke the Admin Artifact to retrieve the FQDN for the Ansible server.

If there are multiple records in the device authentication table then APPC will invoke the Admin Artifact to retrieve the FQDN, Cloud Owner, Cloud Region ID, and Tenant Id.

Precedence factor on the condition for the tenant id and other attributes present in the payload

APPC will support the precedence factor on the condition for the tenant id and other attributes present in the payload.

APPC will verify If the cloud owner, cloud region id, tenant id, VNF management server FQDN (Ansible server cluster FQDN) is sent in the payload.

If yes then APPC will use the values received in the payload in order to find the appropriate VNF management server to connect for the given VNF request.

If not then APPC will use credentials as described above in "Ansible DG enhancement" and "Ansbile adaptor enhancement"

Payload example

Ref link:

Ansible Playbook Examples in VNF Guide.
Ansible Adaptor in APPC

Versions Compared

Old Version 28

New Version Current

Key