ONAP is requesting support for a new manually initiated VNF ScaleOut flow.    APPC will add a new action ConfigScaleOut to support any changes needed to the VNF after instantiation, such as updating the configuration.   The protocols supported for ConfigScaleOut are:

• Netconf (limited to changes done via a configuration update)
• Chef
• Ansible

During substantiation, the VNF is scaled out (one or more VM’s added) using one of the available VF Modules for scaling.   Since there can be multiple scale out VF Modules, the APPC design needs to allow for multiple APPC templates/PD artifact.   Each APPC template is associated with the specific VF Module using the SDC VfModuleModelName.   **  

Assumptions On ConfigScaleOut:

1. ** APPC will support a ConfigScaleOut to allow multiple VM’s to be added to one or more existing VNFC’s (i.e., the ConfigScaleOut cannot create a new VNFC type that was not in the base VF Module)

The VfModuleModelName in SDC maps to the model.model-ver.model-name in A&AI where the model block is associated with the vf-module instance.

This feature is supported as self-service using the APPC CDT tool.

APP-C Design Time Support:

At design time, the self-service user selects the action ‘ConfigScaleOut’ and the protocol.   Since there can be multiple templates for the ConfigScaleOut action, the user is asked to select or enter the key identifier for the template (to be generic, this would be a template identifier).  The value to be entered would be the vf-module-name as stored in A&AI.  The template, param name/value, and PD artifact names in the Reference Data artifact contains the template identifier (note: any spaces and other special characters will be removed when formulating the template artifact names).  The Reference Data artifact also contains a new block with a list of the template identifiers (vf-module-names) associated with the ConfigScaleOut action (this is used for display on the APP-CDT tool).

The ConfigScaleOut block also contains a VM block which has the inventory needed to add the VNFC records.   There is a separate set of VNFC records created for each ConfigScaleOut template.

A template is created and the Parameter Definition data is added. Parameter sources allowed are:

• Manual (i.e., the parameter name/value are provided in the LCM API request payload)
• A&AI

Run-Time Flow:

1. ** The VID user selects the VF Module to be used for ScaleOut. The VID user triggers the VNF ScaleOut instantiation and configuration requests to SO. For the configuration request, the APP-C payload contains one request parameter:  vf-module-id.  The VID user may also need to upload a spreadsheet containing the APP-C configuration instance specific parameter name/values.  The spreadsheet data is converted into JSON format and sent in the request to MSO in the payload (along with the vf-module-id).   Since the plan is to support the ConfigScaleOut action for both APP-C and SDN-C controllers, a new field controller-type with values such as APP-C and SDN-C would be selected.  This field is used by SO to direct requests to the correct controller.  Note: The APP-C design will allow a new field controller_template_id to be included in the payload (in the event that VID needs to provide the unique controller template identifier).**
2. SO executes a workflow for ScaleOut. SO sends a ConfigScaleOut request to APP-C LCM API,  which includes the payload from VID.  APP-C provides a client library that handles interactions between SO and the APP-C (using a message bus for communication).   The  controller-type value from VID is used to select the correct pair of send/receive TopicNames.
3. APPC processes the ScaleOut request from SO (via the message bus). During the process of the request, the APPC:

            a. LCM API handler validates the request schema; if asynch

            b. Dispatcher performs other validations (using existing standard validations)

            c. DGOrchestrator:

                - ** Retrieves VNF/VM/VNFC information from A&AI (based on the vnf-id and vnf-module-id in the request). This includes the VF-Module, Model, and Model-Version blocks.

              - Retrieves the user created template and parameter definition artifacts from MySQL (based on the VNF type from A&AI). New logic is added to select the correct set of artifacts by matching the model-name from A&AI with the artifact names which contain the model-name.)

              - Obtains any instance specific parameter values from the request payload and sources based on the parameter definition

              - Sends the template and instance specific param name/values to the Velocity (VTL) template generator which returns an output payload

              - Calls a Directed Graph/Adapter based on the protocol associated with action and vnf-type. Information such as user-name, encrypted password, port number and context url are obtained from a southbound properties file.

           d. Download Directed Graph

               - Sends the request to the VNF (Netconf) or Server (Ansible/Chef). If Chef/Ansible, the Server executes a cookbook or playbook on the VNF.

              - Returns a success/error response.

           e .DGOrchestrator:

              - Updates the AAI inventory for the newly instantiated VM’s (either creates or updates the VNFC information). Note that APPC will send an asynchronous 501 intermediate failure message to the client (via the message bus) if the update to AAI fails.

             - Retrieves the running configuration from the VNF (using Netconf, Chef, or Ansible) and stores it in the DB;

             - Returns success or error to the Dispatcher/LCM API handler

         f. LCM API handler returns a final success or error message to the client (via the message bus)