ONAP Scale Out Work Flow

ONAP Scale Out Homing and License Flow

APPC

• APP-C shall support new playbooks, cookbooks, NETCONF templates for ConfigScaleOut . After the ConfigScaleOut is completed the new VMs will be In-Service
• Support the existing general VNF HealthCheck

SDC

• SDC shall support accepting an Onboarding package from the VNF Provider. The On-boarding package will specify:
• VNFs with one or more incremental modules which
  • Defines additional resources that can be added to an existing VNF
• Must be complete Heat templates
• Should define logical growth-units or sub-components of an overall VNF
• On creation, receives appropriate Base Module outputs as parameters
  • Provides access to all shared resources (by UUID)
  • Must not be dependent on other Add-On VNF Modules
• Multiple instances of an incremental Module may be added to the same VNF (e.g. incrementally grow a VNF by a fixed “add-on” growth units)
• Each VNF Module (base or incremental) may have (optional) and associated Cinder Volume Module
• Volume modules must correspond 1:1 with a base module or incremental module
• A Cinder volume may be embedded within the base module or incremental module if persistence is not required
• Shared resource UUIDs are passed between the base module and incremental modules via Heat Outputs Parameters (i.e., Base Module Output Parameters)
  • The output parameter name in the base must match the parameter name in the add-on module
• SDC will support a TOSCA Service Model view at the VNFC (VF_Module) level. This view must be made available to the VID users
• SDC will validate the initial_count for the VF Modules is equal to or greater than the min_vf_module_instances

OOF*

• OOF will process Homing and license placement request from MSO.
• OOF will support additional Policies for Scale Out to check the following:
  • If there is enough capacity in the region or close to the region
  • For the VNF Instance, is the license sufficient to satisfy the configuration requested

*This work is to be done in Beijing Release, but it may not be used until a future release since SO may not have the time to develop the request to OOF. 

SDNC

• SDNC will support a Homing request from OOF and verify if the new VMs can be placed in the region provided as input from VID to SO.
• SDNC will accept a request from OOF and verify if there is sufficient capacity within the same region as the existing VNF or within a region which is close to the existing region
• SDNC shall support accepting the Generic-resource-API from SO for Scale Out Request to make the resource allocation.
• SDNC shall support accepting capacity checks from OOF for Scale Out requests
• SDNC shall support the following Rainy Day Handling requirements
  • During processing of the Instantiation steps for the new VF-Modules, if a error detected in WF, SDNC shall send the response with the error code and text to SO. SDNC shall process an abort, retry, skip or rollback request from SO based on the resolution option chosen by the Rainy Day Handling Flow.
  • During processing of the Heat and Resource Assignment request for the VF Module being scaled out, if a failure is detected, SO shall call the Rainy Day Handling flow with the option (Abort or Retry)
  • During configuring the new VMs in the region, if  a failure is detected, SO shall call the Rainy Day Handling flow with the option (skip, retry, abort or rollback).
• SDNC will also support configuration of new instances in the same manner as APPC.  To do so, SDNC must: 
  •  support the DMaaP interface
  • Support Ansible and Chef as well as Netconf
  • Build support for Healthcheck in the same manner as APPC
  • Build support for ConfigScaleOut in the same manner as APPC
  • Support the Design Tool that is currently supported in APPC