Recordings:
The main topic of discussion was the Annex A.5 SOL001 example and SOL001 constructs.
Chesla Wechsler shared info provided by Thinh Nguyenphu (Unlicensed) regarding configurable properties and modifiable properties:
Scope/Context:
- Team is bound by constraints of ETSI NVF
- Team is bound by constraints of OASIS Simple Profile 1.2
- Tried to duplicate info model in TOSCA
Configurable Properties:
- intended for consumption by the VNF instance itself
- can exist at the VNF level and the VNFC level
- takes effect immediately when sent to the instance
Modifiable Properties:
- intended for the VNFM
- VNFM will act on the modifiable properties based on where it is in the lifecycle and what scripts need them
VDU.Compute
- conflates the Compute and the software that will run on that compute into one node type
- restricts cardinality of VNFC to Compute to be 1:1
- it requires the orchestrator to have normative behavior for nodes of type tosca.nodes.nfv.Vdu.Compute
- it requires stating what are really VNFC's requirements of the tosca.nodes.Compute as capabilities of the Vdu.Compute, and the orchestrator would then have to map those to the compute
The spec informs the VNF vendor as to how to use the modifiable and configurable properties, but doesn't provide examples within the document. The properties are set by the vendor independently by deriving from the "base" types. Chesla interprets that to mean that, unlike HPA where there are common keys being defined, that type of approach hasn't yet been defined here. This bears investigation.
We went through the example to try to understand how a TOSCA orchestrator would process the sample. This section of the recording is filled with guesses and assumptions as to what is intended and would benefit from a subject matter expert to clarify the uncertainty.