The ConfigScaleOut action should follow the flow for Configure and ConfigModify.

When retrieving the A&AI information based on the vnf-id, include the vf-module, model, and model-vers blocks.  The specific fields needed in these blocks are:

Vf-module: vf-module-id, model-invariant-id, model-version-id

Model: model-invariant-id, model-vers

Model-vers: model-version-id, model-name

• When processing a new request:
  • If the request payload contains request-parameters.controller-template-id, use this value as the unique template id.
  • If the request does not contain this parameter, then retrieve the model-name value from the model-vers block from A&AI data and use it as the unique template id.
  • Retrieve the template and PD artifacts from asdc_artifacts as usual (based on the action = ConfigScaleOut and vnf-type). If multiple artifacts are returned, use the artifact where the artifact name contains the template id as the last string (it will be preceded by an underscore).  The template id from the request or A&AI should be modified to remove/replace any special characters, per logic as provided by the CDT team.   Here is an example:
    • Template id = “1234567”
    • Modified template id = “1234567”
    • The corresponding template name would look like "template_ConfigScaleOut_newtypeofvnf_0.0.1V_1234567.xml"

When updating the VNFC records in A&AI:

• If the vf-module-id is not provided in the request, then follow the existing logic.
• If there is a vf-module-id in the request, then create or update VNFC records for the VM’s which have been added for ConfigScaleOut. To determine the vnfc records to use, find the records in the vnfc_reference table associated with the template-id in the request payload (request-parameters block).  Use the existing logic implemented for the Configure action to create or update the VNFC records, including setting the values in the status fields (such as orchestration-status).    Notes on group notation logic:
  • first-vnfc-name: Use the vnfc name of the first record with this vnfc-function-code added in the ConfigScaleOut and append the group-notation-value to it. This should be the same logic as currently implemented.
  • fixed-value: The group-notation-value is always assigned as the group-notation-name.  This should be the same logic as currently implemented.
  • relative-value: The group-notation-value of the prior existing vnfc group is incremented by this value. Search for vnfc records in the A&AI inventory where the vnfc-function-code matches the vnfc-function-code of this record.   Find the latest record based on the vnfc naming convention (i.e., the vm name with the highest last three digits).  Using the group-notation value of the latest record, increment by the group-notation-value in the vnfc_reference data.  This should be the same logic as currently implemented.
  • existing-group-name: This is a new value being added.  Find the existing vnfc records in A&AI inventory with the same vnfc-function code as the value in vnfc_reference table.  Verify that the group-notation value is the same for all such records found in inventory.
    • If all records do not have the same group-notation value, write the new vnfc record to A&AI inventory without a group-notation value and continue to the next VM in the vnfc_reference table. A 501 intermediate error message should be sent after all new VNFC records have been added to A&AI.
    • If all records match, use the same group-notation value for the new vnfc record as found in the existing vnfc records.
  • Continue to write vnfc records to A&AI based on the vnfc_reference table until vnfc records have been written to A&AI for each VM associated with the vf-module-id. If the number of VM’s associated with the vf-module-id for ConfigScaleOut is not equal to the number of VNFC records in vnfc_reference table (i.e., there are either more VM’s in A&AI inventory or more VM’s in the vnfc_reference table, generate a 501 intermediate error message with a meaningful error message. 
  • If any other error is encountered, send a 501 intermediate error with a meaningful error message.

[note: this functionality will will be delivered over 2 sprints: Sub-tasks will define what is delivered under each JIRA story]