The concept of resolution-key is to uniquely identify a specific resolution that has been performed for a given action. Hence the resolution-key has to be unique for a given blueprint name, blueprint version, action name
Through the combination of the fields mentioned previously, one could retrieved what has been resolved. This is useful to manage the life-cycle of the resolved resource, the life-cycle of the template, along to share with external systems the outcome of a given resolution.
The exact same concept applies to resource-id / resource-type, which is more geared to uniquely identify a resource in AAI. So for a given AAI resource, say a PNF, you can trigger a given CDS action, and then you will be able to manage the resolved resources bound to this PNF. Even we could have a history of what has been assigned, unassigned for a given AAI resource.
Note: important not to confuse and AAI resource (e.g. a topology element, or service related element) with the resources resolved by CDS, which can be seen as parameters required to derived a network configuration.
I captured this explanation as part of Modeling Concepts#resourceResolution under Storing the result
Great. This helps me a bit forward and I'm closing to the point of understanding this:)
Seems it's a store of "things" for service/xNF that are needed for particular instance in particular environment (network, vim, elements, protocols, related other services/xNFs). Those things are then available to later perform configuration/lcm etc. for the instance.
In't it a bit similar how MDSAL is used?
In't it a bit similar how MDSAL is used?
Exactly, and idea is to provide a different solution than MDSAL, as it has its issues (scalability mostly)
The resolution-key is a external key such as pnf-name/vnf-name/vnf-id/pnf-id/logical-id etc.. that is used to persist the content that is generated as part of the resource resolution component. This notion is captured in the following wiki Modeling Concepts#resourceResolution
For E2E VNF Automation for use cases such as vLB , SO is passing the resolution key as the vnf-name to persist the configlet for vlb post instantiation in CDS table RESOURCE_RESOLUTION_RESULT
. The resolution key and the content that is persisted for vLB use case is captured in the following wiki: E2E Automation vDNS w/ CDS Use Case - ONAP-03-Run Time- Video Demo for vDNS CDS Dublin
Configlets pushed into CDS DB
|