docs/modeling.rst

   1 .. This work is licensed under a Creative Commons Attribution 4.0 International License.
   2 .. http://creativecommons.org/licenses/by/4.0
   3 .. Copyright (C) 2021 Pantheon.tech
   4 .. Modifications Copyright (C) 2021-2023 Nordix Foundation
   5 .. _modeling:
   6
   7 .. toctree::
   8    :maxdepth: 1
   9
  10 CPS Modeling
  11 ############
  12
  13 CPS-Core Modeling
  14 =================
  15
  16 Data Model
  17 ----------
  18
  19 .. image:: _static/cps-modeling-concepts.png
  20    :alt: Basic entities relationship
  21
  22 Basic Concepts
  23 --------------
  24
  25 Administrative entities
  26
  27 - **Dataspace** is a primary logical separation of data.
  28
  29   Any application can define its own dataspace to store the model(s) and data it owns.
  30   Dataspace is uniquely identified by it's name.
  31
  32 - **Schema Set** describes a data model(s).
  33
  34   Schema Set holds reference(s) to single or multiple YANG modules. Schema Set belongs to dataspace
  35   and uniquely identified by its name (within its own dataspace). Same YANG resources (source files) can be
  36   referenced by multiple schema sets from different dataspaces.
  37
  38 - **Anchor** identifies the unique data set (data record) within a dataspace.
  39
  40   Anchor always references a schema set within same dataspace which describes a data model of associated data.
  41   Multiple anchors may reference same schema set. Anchor is uniquely identified by its name (within own dataspace).
  42
  43 Data
  44
  45 - **Data Node** represents a data fragment.
  46
  47   Each data node can have zero or more descendants and together they form a data instance tree.
  48   The data node tree belongs to an anchor.
  49
  50   Data node is representing a data fragment described in a YANG model as a *container* and/or a *list*.
  51   The data described as a *leaf* and/or a *leaf-list* are stored within a parent data node.
  52
  53   The data node position within a tree is uniquely identified by the node's unique **xpath** which can be used
  54   for partial data query.
  55
  56 Querying
  57
  58 - **CPS Path** is used to query data nodes.
  59
  60 .. toctree::
  61    :maxdepth: 1
  62
  63    xpath.rst
  64    cps-path.rst
  65
  66 Additional information on CPS-Core Interfaces
  67 ---------------------------------------------
  68
  69 .. toctree::
  70    :maxdepth: 1
  71
  72    cps-delta-feature.rst
  73
  74 .. Below Label is used by documentation for other CPS components to link here, do not remove even if it gives a warning
  75 .. _cps_ncmp_modelling:
  76
  77 NCMP Modeling
  78 =============
  79
  80 Data Model
  81 ----------
  82
  83 NCMP stores DMI-Plugin and CM Handle relations using a data model described as per this Yang module.
  84
  85 :download:`DMI Yang Module <api/yang/dmi-registry@2022-05-10.yang>`
  86
  87 Note: Although additional-properties are present in the model of the dmi-registry, these are considered private metadata and as such are not queryable.
  88
  89 Basic Concepts
  90 --------------
  91
  92 - **CM-Handle** represents an instance a modeled Network Function(node) in ONAP.
  93
  94     These are stored as Anchors within CPS-Core.
  95
  96     - **CM-Handle States** are used to represent the potential states in which a CM-Handle can transition between.
  97
  98         The 5 possible CM-Handle states are: ADVISED, READY, LOCKED, DELETING, DELETED
  99
 100         **ADVISED** indicates that a CM-Handle has been registered successfully, and is waiting for the module synchronization process to sync the CM-Handle.
 101
 102         **READY** indicates that the CM-Handle has been synced successfully.
 103
 104         **LOCKED** indicates that the CM-Handle has not synced successfully. A retry mechanism within CPS will set the state back to ADVISED after a set time.
 105
 106         **DELETING** indicates that the CM-Handle is currently being deleted.
 107
 108         **DELETED** indicates that the CM-Handle has been deleted successfully.
 109
 110     - **Data-sync state** is the state of the data synchronization process of the CM-Handle
 111
 112         There are 3 possibles states: NONE_REQUESTED, UNSYNCHRONIZED, SYNCHRONIZED
 113
 114         **NONE_REQUESTED** indicates that the data sync is not requested by the user
 115
 116         **UNSYNCHRONIZED** indicates the cm-handle is waiting for the data sync watchdog operation to carry out the sync process
 117
 118         **SYNCHRONIZED** indicates the watchdog process has finished the data synchronization successfully
 119
 120 - **Datastores** represent different views of the cm data.
 121
 122     Datastores are defined for NCMP to access the CPS running or operational datastores. Currently supported datastores are:
 123
 124     +--------------------------------+-------------------------------------+-------------------------+
 125     | Datastore                      | Configurations                      | Data access type        |
 126     +================================+=====================================+=========================+
 127     | Passthrough-operational        | config-true, config-false           | read-only               |
 128     +--------------------------------+-------------------------------------+-------------------------+
 129     | Passthrough-running            | config-true                         | read-write              |
 130     +--------------------------------+-------------------------------------+-------------------------+
 131
 132 Additional information on CPS-NCMP interfaces
 133 ---------------------------------------------
 134
 135 .. toctree::
 136    :maxdepth: 1
 137
 138    ncmp-cmhandle-querying.rst
 139    ncmp-inventory-querying.rst
 140    ncmp-data-operation.rst
 141
 142 CPS-NCMP Scheduled Processes
 143 ----------------------------
 144
 145 .. toctree::
 146    :maxdepth: 1
 147
 148    cps-scheduled-processes.rst