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?
For the onboarding formats based on TOSCA, data types of the input DM will be translated into data types of the internal DM. There can be also other kinds of transformation, like moving properties from nodes to capabilities and policies, reversing relationship direction, generation of workflow constructs, etc
Technically, translation is a simple and straightforward task if both ends of it are stable and well-defined
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:
How can ONAP ensure that a VNFM (or component taking that role) will use the vendor VNFD ?
How a vendor VNF descriptor will be provided to a SVNFM ? Will it be translated in an internal model and then translated back to the original format ? Can we ensure that the translators will ensure the translation to the original format ?
How a vendor VNFD will be tested and verified ? The translation to the internal model is out of the scope ?
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).
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.
13 Comments
jianguo zeng
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?
Weitao Gao
Hi Anatoly,
In Slide 2, I saw multiple DM in onboarding period need "translate" into internal DM. Can u give me more clarification on it?
BR
Victor
Anatoly Katzman
Thinh Nguyenphu
Hi Anatoly,
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.
Anatoly Katzman
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.
Michela Bevilacqua
HI Anatoly,
Some questions:
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 ?
Anatoly Katzman
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
shitao li
Hi Anatoly
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.
Anatoly Katzman
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).
Andrei Kojukhov
Hi Anatoly,
Besides the questions asked by Michela that I second the most I have a couple more:
BR
Andrei
Anatoly Katzman
Yes, 3 times
Priya TG
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.
Regards,
Priya
Anatoly Katzman
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