Scaling Impacts to ONAP Projects

Owned by Scott Blandford
Last updated: Jan 05, 2018Version comment
5 min read

Scaling will impact many Projects within ONAP.  These diagrams will be used to track our progress on where we are in working with each of the teams to get agreement for work to be done within each project to accommodate Scaling

Manual Scale Out

Auto Scale Out

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

Issues

  • To support scaleout, The APPC team would need to do development, but SDC, SO, Policy, etc.. would need to be onboard with the specific use case that we would want to demo.

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

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

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).

SO

  • Scale Out will be supported as a workflow to be scheduled either "Now" or "At a Scheduled time“

  • During the initial Instantiation/orchestration of a VNF and its Modules or a Scale Out request and prior to making the Heat and Resource Assignment request to SDNC, SO will enhance the existing flow to call OOF for Homing and License Placement Optimization. Initial rollout in this release will be for L4-L7 VNFs. Note: This requirement will be common across Instantiation and Change Management.

  • SO shall pass the whole Order information obtained from VID to OOF in the Placement Container request. The placement Container will include the Service Model info, Subscriber Info, Demand Info, Order Info, Policy ID (optional) and Service Instance Id. SO will support a new workflow with Building Blocks for Scale Out Change Management workflow

  • SO shall accept and process a Scale Out request per VF-Module from VID. The request should include but not limited to: VNF Type, Region, the VF-Modules to be added and the quantity to be added. In addition, information needed to support making a Homing, License Optimization Placement request to OOF and Capacity checks to SDNC and AAI will be included in the request.

  • SO shall support sending the Generic-Resource-API  to SDNC to process Heat and Resource Assignments for L4-L7 VNFs for  Scale Out requests.

  • SO shall support 1 or 2 places in the Scale Out Workflow where Ops may choose to insert a manual task to pause the WF.

  • •SO will perform the following checks for the Scale Out Request from VID:

    • Check if the base Module is being requested, if so fail the request (BAU)

    • SO will check the VF Module level Max instances property, max_vf_module_instances to determine whether the VF_Module can be added to the VNF.

    • SO will check AAI to determine how many VF Module instances are In service and compare that to the Max Instance property to determine whether the VF-Module should be allowed.

      • If the VF-Module cannot be added, SO shall return an error message to VID

  • Rainy Day Handling Requirements

    • During processing of the Instantiation steps for the new VF-Modules, if an error is detected in WF, SO shall enhance the Rainy Day Handling flow to provide resolution options at different stages of the Instantiation Flow. These are new requirements and will require additional building blocks.

    • 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).

VID

  • VID shall allow the Operations user to choose a Scale-Out workflow. (NEW)

  • VID will allow the user to select the Subscriber_>service type-> NF_Role-> Source_VF_Model_Version _>list of VNFs that needs to be scaled out i.e add VF Module(s) that may have one or more VMs in it (NEW).

  • Should VID allow the user to scale out multiple VF_modules within the same VNF.

  • VID will allow the user to add the quantity of VF-Modules to be scaled out for the given VNF . (NEW)

  • Upon selecting the NF-Role, VID will query A&AI, Get-Generic-VNF, to retrieve the "In-Service" View of all the VNFs with a prov-status =PROV.

  • For the NF_Role selected, VID will present a list to the user of VNFs with a prov-status=PROV.

  • VID will present a In Service View that shows the VF_Module and the VM(s) within each VF-Module associated with the VNF

  • VID will check AAI to determine how many VF Module instances are In-Service and compare that to the Max Instance property, max_vf_module_instances, to determine whether the VF-Module should be allowed.

  • VID will specify the region, NF-Role, Number of VF-Modules to be added, homing, capacity and license placement information in the request to MO

  • VID will  to invoke an API to Pause the Scale Out WF (New)

  • VID will allow the user to Cancel the Scale Out WF if the Scale Out run time execution has not started. (NEW)