Agree to the point: that there may be inconsistent inheritance or excessive inheritance , and there's quite some common logic can be share between different model (such as TOSCA and heat etc). So if there's a common and unified internal DM, then it can help.
But how can we assure the new unified model will became another TOSCA or heat as time pass by, because as time pass, requirement will also changes. Currently, if we create a common BPMN process logic for TOSCA DM based in R2, can it be look as also a unified model driven internal DM?
Or, how can prove that invent a new DM will be more stable or more common than extend based on R2+ DM?
In Slide 2, I saw multiple DM in onboarding period need "translate" into internal DM. Can u give me more clarification on it?
would you please clarify your response #1. I am really concern about transformation or moving certain properties into capabilities or policies type in TOSCA. How would transformation perform if the properties has a function such as get_input or get_property.
Thinh, your concerns are very valid, complicated type transformations can boost the translation complexity. I hope that we will be able to avoid complicated transformations in most cases. For example, some data types definitions can be just imported from the source model into the destination model, and then the values of these types can be just copied.Other data types will be so similar (being based on the same IM) that transforming them would be as simple as renaming of some of their sub-properties.The most challenging case is conversion with restructuring; this can be done on sub-property basis.
You are also right that when a property moves from a node type to a capability type, then some get_property occurrences may also need a refactoring to reflect the changed path to the source property.
I am not saying it can be done in no time, but this is all doable and simpler than our current HEAT-to-TOSCA conversion.
1) slide 3, "Full preservation of the on-boarded information" raises doubts:
2) Has ONAP provided a clear role to the TOSCA orchestration? Is there a directive on this ?
3) Can you clarify the role of the ONAP internal model in the onboarding phase in slide 2?
5) Is the proposal covering also ETSI VNFD ir it is proposed for ETSI NDS too ?
1a. If the VNFM is TOSCA-native, than the internal DM should be good enough to drive its operation. If the VNFM is hardcoded to use specific node types, property names, etc, than it either should be refactored or maybe provided the original VNFD wrapped as an artifact.
1b. Back and forth translation sounds really bad. See 1a. Can SVNFM be refactored? Maybe originalVNFD as an artifact would be the solution?
1c. It is obviously very important to verify the models after translation. The validation logic should be applied to the internal format
3. A vendor may choose to define his/her VNFD in the terms of the internal DM. In this case, the VNFD will be onboarded with zero translation.
5. If we decide to onboard ETSI NSDs, than yes, it will be a valid onboarding model supported by translation
what do you mean by TOSCA-native VNFM? TOSCA Orchestrator based on tosca-simple-profile-yaml? I think it is not enough, in order to correctly process the model, the VNFM has to support the new information (classes and data types) as defined in ONAP IM, so in ONAP R2 DM, we introduce a lot of new TOSCA types (data types, node types, capablity types), but that does not mean it is a hardcoded solution, those now types are just elements which can be used to model various VNF descriptors.
Another thing is that the current SOL001 spec (which ONAP R2 DM based on) comply with TOSCA grammar, so it is possible for developing a VNFM based on the native TOSCA Orchestrator to support the current ONAP R2 DM.
TOSCA-native means that it relies on tosca-simple-profile-yaml as much as possible. New types are totally okay too, as long as their purpose is limited to structuring, documenting, and re-using of information. But adding new types stops being cool at the point where a new type brings with it an expectation for some special interpretation by external logic (like shown on the slide "Examining R2+ Data Model").I intentionally say "as much as possible" here, I do realize that it will not always be possible to fully rely on the tosca-simple-profile-yaml. This profile still has many gaps, and we cannot wait for a clean resolution by the slow OASIS TC. In these cases, we will be forced to quickly fix these gaps with some implementation conventions and hardcoded logic. But even in these cases, we should continue working on a cleaner, long-term model-driven solution (for example, by our contributions to the TOSCA simple profile).
Besides the questions asked by Michela that I second the most I have a couple more:
Yes, 3 times
Anatoly, regarding your response to Shitao's comment - SOL 001 specification defines NFV specific types. Though the Orchestrator is compliant with the grammar specified by TOSCA Simple Profile specifications, it also has to recognize and translate all these types to internal DM to be able to successfully orchestrate the VNFs.
It is easy to say "has to recognize". But please understand the costs of this "has to" for the R2+ DM:
1. endless re-writing the orchestrator code - per node type, per relationship, even per data type
2. Inability to replace this deeply customized orchestrator with anything else TOSCA-driven
Powered by a free Atlassian Confluence Open Source Project License granted to The Linux Foundation. Evaluate Confluence today.