How Data Dictionary is updated as part of service CBA distribution?

2 answers

1.  

   2

   1

   0

   • Yuriy Malakov
   • Sep 08, 2019

   Samuli Silvius The CBA Package include the parameter and dictionary mapping for each velocity and/or jinja template file. This notion is explained in the modeling concept: Modeling Concepts#artifact-mapping-resource

   
   

   For example, the vLB Dublin use case contains 8 mapping files that provide a parameter to data dictionary mapping. https://github.com/onap/ccsdk-cds/tree/master/components/model-catalog/blueprint-model/service-blueprint/vLB/Templates

   
   

   base_template-mapping.json

   baseconfig-mapping.json

   incremental-config-mapping.json

   nf-params-mapping.json

   vdns-mapping.json

   vdns-vnf-mapping.json

   vlb-mapping.json

   vpkg-mapping.json

   
   

   
   

   In addition, as part of the enrichment process for each of the dictionary name cds retrieves all the global defition and stores them as part of the Definition folder in the resources_definition_types.json file.  This notiion is explained in modeling concept wiki: Modeling Concepts#818143235

   
   

   
   

   For example, vLB Dublin use case has the following definition for file resources_definition_types.json

   https://github.com/onap/ccsdk-cds/blob/master/components/model-catalog/blueprint-model/service-blueprint/vLB/Definitions/resources_definition_types.json

   
   

   •  Comment

   1. Samuli Silvius

      • Sep 08, 2019

      Those links to Modeling Concepts e.g. Modeling Concepts#818143235 just goes to main page of the documentation.

      I'm sorry but I really have not been able to extract this information from those pages.

      From your answer, if I understood, enrichment creates resource_definition_types.json file and that content is somehow pushed to Data Dictionary? 

      So when I remove the CBA and model another one, Data Dictionary still have those entries left from the first CBA? So those can be re-used.

      
      

   2. Alexis de Talhouët

      • Sep 09, 2019

      From your answer, if I understood, enrichment creates resource_definition_types.json file and that content is somehow pushed to Data Dictionary?

      Note quite, Data Dictionary need to exist before you perform the enrichment, else enrichment will fail saying it wasn't able to find the referenced DD.

      So when I remove the CBA and model another one, Data Dictionary still have those entries left from the first CBA? So those can be re-used.

      Yes, that's the idea.

   CommentAdd your comment...
2.  

   1

   0

   -1

   • Alexis de Talhouët
   • Sep 09, 2019

   But examples has only CBA files but no DD file(s):
   https://github.com/onap/ccsdk-cds/tree/master/components/model-catalog/blueprint-model/service-blueprint

   Actually they do, as part of the enrichment process, all the data dictionaries referenced from within the mapping files will be gathered under the resources_definition_types.json

   I updated Modeling Concepts#Enrichment to clarify on this.

   is the DD supporting now all the known example CBAs?

   Yes, this is correct. The DDs present in the starter-dictionary folder are the ones required for the service-blueprints.
   The DDs present in the test-dictionary are the ones required for the test-blueprints.

   Would't it be better to support DD import from CBA directly so CBA would be complete?

   Somewhat, through Enrichment, this is the case already. But the question is very valid, we have had a few discussion around having the CBA containing the DD it requires directly, rather than referencing to global, shared DD. This is, or will be,  on our roadmap for Frankfurt.

   But initial idea is still valid, there might be a set of DD that can be shared all across CBA, hence we still want the ability to have DD design being a standalone activity as well.

   •  Comment

   1. Samuli Silvius

      • Sep 09, 2019

      Yes, this clarifies a lot! And thanks for all the time updating ModelingConcepts page with clarifications.

      
      

      Sharing DD items between CBAs makes a lot of sense. So basically CBA's resource_definition_types.json is only a reference (by data_types.json) to standalone DD. That was not explicitly understandable because the content is exactly the same i.e. one can assume resource_definition_types.json content could be pushed (internally by CDS using DD APIs) to DD.

      
      

      Also selfcontained CBA is important. Maybe there should be a way to provide DD item within CBA and that would override global DD (if they have same item) item for this CBA only. And default way would be like it is now, all DD items from global.

        

   CommentAdd your comment...