...
- 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
SO we 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 | TOSCA CSAR | Comment |
|---|---|---|
| service | "hpaPolicy" | |
| policyName | OSDF_CASABLANCA + . + content.getIdentity() | |
| description | "OOF Policy" | |
| templateVersion | "OpenSource.version.1" | |
| version | 1.0 | |
| priority | 5 | |
| riskType | "Test" | |
| riskLevel | 2 | |
| guard | False | |
| content.resources | content.getResources().add(metaData.getValue("name")); | the resource name defined in SDC |
| content.identity | content.getPolicyType() + "_" + metaData.getValue("name") | |
| content.policyScope | “HPA” sdcCsarHelper.getServiceMetadata().getValue("name"); | List |
| content.policyType | "hpa" | |
| content.flavorFeatures.id | node.toString | the name of the VDU node |
| content.flavorFeatures.type | "tosca.nodes.nfv.Vdu.Compute" | |
| content.flavorFeatures.directives.type | "flavor_directives" | |
| content.flavorFeatures.directives.attributes.attribute_name | "flavor_name" | |
| content.flavorFeatures.directives.attribute_value | "" | placeholder |
| content.flavorFeatures.flavorProperties | based on HPA Policies and Mappings | |
| content.flavorFeatures.flavorProperties.directives | [ ] | OOF fill them in |