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
- VNFs with one or more incremental modules which:
- 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)
8 Comments
Alexander Vul
Scott,
This use case overlaps with some of the work that I am looking to do in support of the Hardware Platform Enablement use case. How do you want to handle this?
Alex
Scott Blandford
I am out the rest of the year, but lets definitely get together the first week of January to understand the overlaps. It would be helpful if you can send me a list of the overlaps via email in the mean time. That way I can look them over and have others think about them during the break.
Thanks,
Scott
Alexander Vul
Will do...
Milind Jalwadi
In the current Amsterdam release there is an issue with scale out scenario where in we cannot scale out multiple times. We can scale out only once in the lifetime of a vDNS use case. To overcome this issue, two stories were suggested as below -
POLICY-503 - Getting issue details... STATUS and SO-361 - Getting issue details... STATUS
The above were suggested with reference to Amsterdam architecture. But with new VNF Scale out use case proposal for R2, there would be some changes. But the logic or solution suggested in the JIRA stories would have to be accommodated in APP-C and SO. Specially the usage of AAI data model that captures VF Module details.
Along with the "max_vf_module_instances" check, we shall also need usage of field "orchestration-status" to distinguish between orchestrated and non-orchestrated VF modules. The details of this usage has been captured in above stories.
Accordingly the text that describes validation in SO would need to be updated in this page.
Scott Blandford
Milind, At this point only Manual Scale Out will be done in Beijing. However we should take the time now to determine how we want to efficiently handle Auto Scaling as a part of Casa Blanca. I think both of your work items listed will be helpful, but we probably need to set them within a larger context of how auto scaling should work for all VNFs.
Milind Jalwadi
Hi Scott, Yes, Precisely! The scaling should work for all the VNFs and not only for few built in use cases like vDNS. To have this feature supported, below items need to be taken care of -
A. For every scale-out, the new cloud stack name to be dynamically generated and should be unique. The previous scaling stack name with incremented suffix count could be one option.
B. For every scale-out, the instance name should be dynamically generated. Suffixing the incremented value of instance count to the base scaling instance name could be one option. This could be enforced in HEAT or TOSCA templates, or alternatively could be provided by SO as a parameter while invoking API on a multi cloud component during instantiation.
C. The SDNC configuration required for new instance to be scaled-out should be taken care in an automated manner and should not be manual as is the case in current Amsterdam release.
All the above aspects have been taken care of in the solution described in stories POLICY-503 and SO-361, with reference to Amsterdam architecture.
One thing to note is that there would be several parameters like instance name, stack name etc. that SO may want to pass in the API to multi cloud component overriding the HEAT specifications. This is something that could be supported in the subsequent releases.
Pamela Dragosh
As Scott said - auto scaling is pushed to Casablanca but only in the case of moving to APPC. This however takes quite a bit of effort for APPC to scope and implement.
So in the meantime, any help to alleviate the existing vDNS use case such that it can scale out multiple times is very valuable and I know that Brian Freeman is pleased that you folks can help with it.
As with Amsterdam, once Beijing is released companies and teams will use that Beijing version for deploying internally and/or POCs, etc. So if we can fix this limitation it is extremely valuable.
Milind Jalwadi
Hi Pam - Agreed. But from the architectural stand point, we should invoke the same SO work flow that shall be invoked for the manual scenario. Hence finalizing the information elements to be passed to this new SO workflow is very important. Once this is known, we can evaluate the changes to be done in policy to support the vDNS scaling for multiple times and in an automated way.