Ankitkumar Patel: Summarizing the discussion of this email thread to just make sure that we all are on the same page.
The HPA requirements of a VNF are extracted from a VNF descriptor and captured in a TOSCA model in a tuple format (for the sake of extensibility purpose). Some of these requirements cannot be change during the lifecycle of a service; while the other optional requirements can be overwritten by a service designer or operator (For example, the use of SR-IOV may be preferred by an operator if a VNF can support SR-IOV and a vendor does not have a preference). Once a service model is designed and uploaded into the SDC repository, the policy service is notified. The policy service then fetches the TOSCA model, extracts out the HPA requirements from TOSCA through decomposition, composes the HAP HPA polices for the homing service (OOF-HAS), and stores in the policy repository. When the homing service receives a homing request from SO, the homing service asks for the associated HPA policies from the policy platform. Based on the received HPA policies, the homing solution service finds and returns the placement solutions.
Here are the example of the currently supported OOF-HAS policies.
OOF Policy Examples
OOF-HAS Policy Examples
| Section |
|---|
|
| Column |
|---|
| | Code Block |
|---|
| language | js |
|---|
| theme | Eclipse |
|---|
| title | HPA Hyper-Threading Policy ExampleConfluence |
|---|
| linenumbers | true |
|---|
| collapse | true |
|---|
| {
"service": "HPA_Hyper_Threading_Policy",
"policyName": "OOF_Beijing.vGMuxInfra",
"description": "Hyper threading policy for vGMuxInfra",
"templateVersion": "0.0.1",
"version": "ONAP_Beijing",
"priority": "3",
"riskType": "test",
"riskLevel": "2",
"guard": "False",
"content": {
"hyper_threading_properties": {
"cpu_cores": {
"magnitude": 4,
"operator": "=",
"unit": ""
},
"cpu_threads": {
"magnitude": 2,
"operator": "=",
"unit": ""
},
"cpu_threads_policy": {
"magnitude": "dedicated",
"operator": "=",
"unit": ""
},
"cpu_sockets": {
"magnitude": 2,
"operator": "=",
"unit": ""
}
},
"identity": "hyper_threading_vGMuxInfra",
"policyScope": {
"serviceType": ["vCPE"],
"geoRegion": ["US", "INTERNATIONAL"],
"networkType": ["ip"],
"resourceInstanceType": ["vGMuxInfra"]
},
"type": "HPA_hyper_threading",
"resourceInstanceType": ["vGMuxInfra"]
}
} |
|
| Column |
|---|
|
| Expand |
|---|
| The values in this exemplary policy are populated from a TOSCA service model by the policy platform |
Line 1: The primary challenge is when to schedule changes such that service disruption is minimized. OF offers the CMSO service to the CM application, which can be invoked prior to any change are scheduled. A service designer designs a change request in SDC and configures the schedule requirements through policies. Prior to scheduling changes via Service Orchestrator (SO), the designer makes a call to CMSO from SDC. CMSO collects the existing scheduling information from available ticketing system and vertical dependency information from AAI and calculates a solution to the scheduling application. Finally, the recommended schedule is returned to SDC, which is verified by the designer before committing the schedules to SO |
|
