aboutsummaryrefslogtreecommitdiffstats
path: root/docs
diff options
context:
space:
mode:
authorDan Timoney <dtimoney@att.com>2019-04-16 13:35:44 +0000
committerGerrit Code Review <gerrit@onap.org>2019-04-16 13:35:44 +0000
commit8816b6d4beee1aa86a405f2c259df4036282bb09 (patch)
treea86a7405328a4c4317a1f5a244956bc242cd0930 /docs
parent4dae1b2293ac35a68b59b3f936102a2d24538b24 (diff)
parentfe6afae79cf6a0409a06b6da8224debcbb05c00f (diff)
Merge "Resource dictionary index update"
Diffstat (limited to 'docs')
-rw-r--r--docs/datadictionary/index.rst87
1 files changed, 62 insertions, 25 deletions
diff --git a/docs/datadictionary/index.rst b/docs/datadictionary/index.rst
index 83c6e47b8..a7e78564f 100644
--- a/docs/datadictionary/index.rst
+++ b/docs/datadictionary/index.rst
@@ -9,37 +9,74 @@ Resource Definition
Introduction:
=============
-A Resource Definition defines a specifc resource that can be resolved using the bellow supported sources.
+A data dictionary models the how a specific resource can be resolved.
-A Resource Definition can support multiple sources.
+A resource is a variable/parameter in the context of the service. It can be anything, but it should not be confused with SDC or Openstack resources.
-The main goal of Resource Definition is to define generic entity that could be shared accross services.
+A data dictionary can have multiple sources to handle resolution in different ways.
+The main goal of data dictionary is to define re-usable entity that could be shared.
-Resolution sources:
-===================
+Creation of data dictionaries is a standalone activity, separated from the blueprint design.
- * Input
- * Default
- * DB
- * REST
- * Capability
-Artifacts:
-==========
+As part of modelling a data dictionary entry, the following generic information should be provided:
- * artifact-mapping-resource
- * artifact-template-velocity
- * artifact-directed-graph
+|image0|
-Node type:
-==========
-
- * component-resource-resolution
- * component-jython-executor
- * component-netconf-executor
- * component-restconf-executor
+.. |image0| image:: media/image0.jpg
+ :width: 7.88889in
+ :height: 4.43750in
-Data type:
-==========
- * vnf-netconf-device \ No newline at end of file
+Bellow are properties that all the resource source have will have
+
+The modeling does allow for data translation between external capability and CDS for both input and output key mapping.
+
+|image1|
+
+.. |image1| image:: media/image0.jpg
+ :width: 7.88889in
+ :height: 4.43750in
+
+Example:
+========
+
+vf-module-model-customization-uuid and vf-module-label are two data dictionaries. A SQL table, VF_MODULE_MODEL, exist to correlate them.
+
+Here is how input-key-mapping, output-key-mapping and key-dependencies can be used:
+
+vf-module-label data dictionary
+
+{
+ "name" : "vf-module-label",
+ "tags" : "vf-module-label",
+ "updated-by" : "adetalhouet",
+ "property" : {
+ "description" : "vf-module-label",
+ "type" : "string"
+ },
+ "sources" : {
+ "primary-db" : {
+ "type" : "source-primary-db",
+ "properties" : {
+ "type" : "SQL",
+ "query" : "select sdnctl.VF_MODULE_MODEL.vf_module_label as vf_module_label from sdnctl.VF_MODULE_MODEL where sdnctl.VF_MODULE_MODEL.customization_uuid=:customizationid",
+ "input-key-mapping" : {
+ "customizationid" : "vf-module-model-customization-uuid"
+ },
+ "output-key-mapping" : {
+ "vf-module-label" : "vf_module_label"
+ },
+ "key-dependencies" : [ "vf-module-model-customization-uuid" ]
+ }
+ }
+ }
+}
+
+
+Resource source:
+================
+
+Defines the contract to resolve a resource.
+
+A resource source is modeled, following http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.0/csprd01/TOSCA-Simple-Profile-YAML-v1.0-csprd01.html#DEFN_ENTITY_NODE_TYPE, and derives from the https://wiki.onap.org/display/DW/Modeling+Concepts#ModelingConcepts-NodeResourceSource \ No newline at end of file