High-level:
The Definition of high-level TOSCA DM about HPA could refer to Supported HPA Capability Requirements(DRAFT). The example, which acts as a resource of SDC, could refer to [demo.git] / tosca / vCPE /
SDC leverages the resource to set up a service, an example output of the service is attached: service-VcpeWithAll-csar.csar
Low-level:
There are several components, which acts of SDC client, to parse the output CSAR to do interactive:
- SO: sends out homing requests to OOF by parsing the CSAR, which includes OOF will respond with the most appropriate flavors accordingly
- Policy: after user distributes the service, it will download the related CSAR and dynamically generate the policies based on specified rules.
- VFC: sends out homing requests to OOF by parsing the CSAR, which includes OOF will respond with the most appropriate flavors accordingly
The flow of HPA like below:
- Policy generates policies after user distributes SDC service by parsing CSAR
- TOSCA: VFC sends homing requests to OOF by parsing the SDC CSAR
- HEAT: SO sending homing requests to OOF by parsing the SDC CSAR
- OOF fetch policies from Policy based on the input from VFC or SO
- OOF fetch flavor from AAI based on the received policies
- OOF composite the output to VFC or SO
We need to keep alignment about the how to parse the SDC CSAR, the mapping from CSAR to low-level fields. below is the logic of Policy side used, the format example refer to OOF R3 HPA & Cloud Agnostic policies
| Policy | Const value or from TOSCA CSAR | Value | Comment |
|---|---|---|---|
| service | Const | "hpaPolicy" | |
| policyName | TOSCA CSAR | "OSDF_CASABLANCA."+ content.getIdentity() | |
| description | Const | "OOF Policy" | |
| templateVersion | "OpenSource.version.1" | ||
| version | "1.0" | ||
| priority | "5" | ||
| riskType | "Test" | ||
| riskLevel | "2" | ||
| guard | "False" | ||
| content.resources | TOSCA CSAR | content.getResources().add(metaData.getValue("name")); | the resource name defined in SDC |
| content.identity | TOSCA CSAR | content.getPolicyType() + "_" + metaData.getValue("name") | |
| content.policyScope | Const TOSCA CSAR | “HPA” sdcCsarHelper.getServiceMetadata().getValue("name"); | List |
| content.policyType | Const | "hpa" | |
| content.flavorFeatures.id | TOSCA CSAR | node.toString | the name of the VDU node |
| content.flavorFeatures.type | Const | "tosca.nodes.nfv.Vdu.Compute" | placeholder |
| content.flavorFeatures.directives.type | "flavor_directives" | ||
| content.flavorFeatures.directives.attributes.attribute_name | "flavor_name" | ||
| content.flavorFeatures.directives.attribute_value | "" | ||
| content.flavorFeatures.flavorProperties.hpaFeature | TOSCA CSAR | one of available or meaningful values: cpuTopology, basicCapabilities, ovsDpdk, cpuPinning, numa, sriovNicNetwork, pciePassthrough, localStorage, instructionSetExtensions, hugePages based on below Feature judgement flow | based on HPA Policies and Mappings |
| content.flavorFeatures.flavorProperties.mandatory | from mandatory field | ||
| content.flavorFeatures.flavorProperties.architecture | from hardwarePlatform field | ||
| content.flavorFeatures.flavorProperties.hpaVersion | "v1" | ||
| content.flavorFeatures.flavorProperties.hpaFeatureAttributes | parse and tiny change from configurationValue | ||
| content.flavorFeatures.flavorProperties.directives | [ ] | OOF fill them in |