Page Comparison

...

• 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 add the records to the DT_Artifacts_tracking tables (in addition to the asdc_artifacts table for the Admin Artifact):

• APP-C shall 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 apply the following steps:

1. 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. 1. 1. APP-C is assuming that currently all the vserver objects for a given VNF in A&AI are the same.
               2. APP-C 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 lookup these 3 attributes in the Admin Artifact.

                                          i.    If the matching the cloud-owner, cloud-region-id & Tenant-id is found, then APP-C shall read the vnf-management-server-fqdn

1. 1. 1. 1. 1. 1. Using the VNF-type, Protocol <ANSIBLE>, Action, vnf-management-server-fqdn, APP-C shall lookup the record in the device authentication table to find the user name and password.
                  1. If record found from the device authentication table then APP-C shall continue with the POST request to the Ansible Rest API call.
                  2. If record was not found, then APP-C shall 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 shall 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>”

Payload example

Ref link:

1. 1. Ansible Playbook Examples in VNF Guide.
   2. Ansible Adaptor in APPC