docs/sections/design-components/DCAE-MOD/DCAE-MOD-Architecture.rst

   1 .. This work is licensed under a Creative Commons Attribution 4.0 International License.
   2 .. http://creativecommons.org/licenses/by/4.0
   3
   4 =====================
   5 DCAE MOD Architecture
   6 =====================
   7
   8
   9 DCAE MOD is composed of a mix of components developed in ONAP and other
  10 components taken from the Apache Nifi project and modified for
  11 appropriate use. The MOD architecture and design was intended to simplify the onboarding
  12 and design experience in ONAP addressing below goals.
  13
  14 .. toctree::
  15    :maxdepth: 1
  16
  17    ./DCAE-MOD-goals.rst
  18
  19
  20 MOD aims to streamline the construction, management,
  21 and evolution of DCAE flows from role to role, from environment to
  22 environment, and from release to release. MOD is composed of three functional areas: onboarding, design, and
  23 distribution and caters to different `user group <./Roles>`__
  24
  25
  26 The below illustrations describe the architecture of DCAE-MOD and show the
  27 usage flow in DCAE MOD
  28
  29 |image0|
  30
  31 |image1|
  32
  33 Onboarding API
  34 --------------
  35
  36 It is a component developed to onboard
  37 models/components/microservices (spec files) into DCAE MOD.
  38
  39 Genprocessor
  40 ------------
  41
  42 It has been developed in Java. This project is a tool to
  43 experiment with generating a Nifi Processor POJO from a DCAE component
  44 spec.
  45
  46 Nifi Web UI
  47 -----------
  48
  49 It is a component taken from the Apache Nifi Project but modified for
  50 use in the MOD project.
  51
  52 Apache NiFi is a dataflow system based on the concepts of flow-based
  53 programming. It supports powerful and scalable directed graphs of data
  54 routing, transformation, and system mediation logic. NiFi has a
  55 web-based user interface for design, control, feedback, and monitoring
  56 of dataflows. It is highly configurable along several dimensions of
  57 quality of service, such as loss-tolerant versus guaranteed delivery,
  58 low latency versus high throughput, and priority-based queuing. NiFi
  59 provides fine-grained data provenance for all data received, forked,
  60 joined cloned, modified, sent, and ultimately dropped upon reaching its
  61 configured end-state.
  62
  63 The NiFi UI provides mechanisms for creating automated dataflows, as
  64 well as visualizing, editing, monitoring, and administering those
  65 dataflows. The UI can be broken down into several segments, each
  66 responsible for different functionality of the application. This section
  67 provides screenshots of the application and highlights the different
  68 segments of the UI. Each segment is discussed in further detail later in
  69 the document.
  70
  71 The users of Apache Nifi will find that it is used very differently than
  72 intended to serve our purpose in the DCAE-MOD project.
  73
  74
  75 Registry API
  76 ------------
  77
  78 This component taken from the Apache Nifi project, is a REST API that
  79 provides an interface to a registry with operations for saving,
  80 versioning, reading NiFi flows and components.
  81
  82 Distributor API
  83 ---------------
  84
  85 It is a component developed using the Flask framework in Python.
  86 It is a HTTP API to manage distribution targets for DCAE design.
  87 Distribution targets are DCAE runtime environments that have been
  88 registered and are enabled to accept flow design changes that are to be
  89 orchestrated in that environment.
  90
  91 Flow Based Programming (FBP)
  92 ----------------------------
  93
  94 NiFi’s fundamental design concepts closely relate to the main ideas of
  95 Flow Based
  96 Programming `[fbp] <https://nifi.apache.org/docs/nifi-docs/html/overview.html#fbp>`__.
  97
  98 For more information on how some of the main NiFi concepts map to FBP,
  99 check out https://nifi.apache.org/docs/nifi-docs/html/overview.html
 100
 101 Runtime API
 102 -----------
 103
 104 It is developed in Java’s Spring Boot framework. It
 105 is a HTTP API to support runtime environment for DCAE-MOD. It has two
 106 major functionalities:
 107
 108 1. It accepts changes on the flow-graph via fbp protocol
 109
 110 2. It generates and distributes helm charts OR blueprints based on the change made on
 111    the flow-graph
 112
 113
 114 Build Updates
 115 ~~~~~~~~~~~~~
 116
 117 New Java module - Helmgenerator-core was introduced for Helm charts
 118 generation. MOD/Runtime has been enhanced to include this new dependency
 119 (inaddition to Bp-generator for supporting cloudify blueprints flows).
 120
 121 Below is snippet from -
 122 https://github.com/onap/dcaegen2-platform/blob/master/mod/runtimeapi/runtime-core/pom.xml
 123
 124 ::
 125
 126         <dependency>
 127             <groupId>org.onap.dcaegen2.platform</groupId>
 128             <artifactId>helmchartgenerator-core</artifactId>
 129             <version>1.0.3</version>
 130         </dependency>
 131
 132
 133 Chart Updates
 134 ~~~~~~~~~~~~~
 135
 136 MOD/Runtime Charts has been modified to include under resources, common
 137 base templates, Charts.yaml, add-on templates and Values.yaml with
 138 placeholder.
 139
 140 |image3|
 141
 142 The Helmgenerator-core modules uses these template to pull the required
 143 dependencies and generate new chart for MS onboarded. The parameters in
 144 component-spec provided during onboarding is used for final Values.yaml
 145 file generation.
 146
 147 Deployment
 148 ~~~~~~~~~~
 149
 150 The MOD/RuntimeAPI introduces new configuration to identify distribution
 151 mechanism. Supported artifactType are **BLUEPRINT** or **HELM. **
 152
 153 Blueprint – Distribution to Inventory/Dashboard
 154
 155 Helm – Distribution to ChartMuseum
 156
 157 For Jakarta release, the charts configuration has been set to support
 158 HELM distribution by default and configured for ONAP-internal
 159 chart-museum registry.  RuntimeAPI Chart updates
 160 https://github.com/onap/oom/blob/master/kubernetes/dcaemod/components/dcaemod-runtime-api/values.yaml
 161
 162 ::
 163
 164   artifactType: "HELM"
 165   registryBaseurl: http://chart-museum:80
 166   basehelmchartlocation: /helm-gen/
 167
 168
 169 Blueprint Generator
 170 -------------------
 171
 172 This tool allows the user to create a blueprint from a component spec json file.
 173 This tool is used by the runtime api when artifactType is set to **BLUEPRINT** under
 174 `RuntimeAPI charts
 175    deployment <https://git.onap.org/oom/tree/kubernetes/dcaemod/components/dcaemod-runtime-api/values.yaml#n44>`__
 176
 177 Helm Generator
 178 --------------
 179
 180 This tool allows the user to create a DCAE Services helm chart from a component spec json file.
 181 This tool is used by the runtime api when artifactType is set to **HELM** under
 182 `RuntimeAPI charts
 183    deployment <https://git.onap.org/oom/tree/kubernetes/dcaemod/components/dcaemod-runtime-api/values.yaml#n44>`__
 184
 185
 186 Inventory API
 187 -------------
 188
 189
 190 .. note::
 191    Used only under BLUEPRINT mode
 192
 193 DCAE Inventory is a web
 194 service that provides the following:
 195
 196 1. Real-time data on all DCAE services and their components
 197
 198 2. Comprehensive details on available DCAE service types
 199
 200 DCAE Inventory is a composite API that relies on other APIs to obtain
 201 resources on underlying components and uses these resources to compose a
 202 DCAE service resource. In addition, DCAE Inventory will store data that
 203 is unique to the DCAE service level including:
 204
 205 1. DCAE service metadata
 206
 207 2. DCAE service type description and composition details
 208
 209 3. Relationships between DCAE service and DCAE service types and their
 210    respective VNF and VNF types
 211
 212 DCAE Inventory has a REST interface to service client requests. It has a
 213 well-defined query interface that would filter result sets based upon
 214 resource attributes.
 215
 216 Here, think of it as a back end API for the DCAE dashboard. The runtime
 217 posts Cloudify Blueprints to this API so they show up in the DCAE
 218 dashboard.
 219
 220 DCAE Dashboard
 221 --------------
 222
 223 .. note::
 224    Used only under BLUEPRINT mode
 225
 226 The DCAE dashboard provides visibility into running DCAE services for
 227 operational purposes. It queries the DCAE Inventory for aggregate
 228 details on all the running DCAE services and for getting up-to-date
 229 status information on DCAE services and their components.
 230
 231 End-to-End Flow
 232 ---------------
 233
 234 A model/component/microservice can be onboarded by a ms Developer by
 235 posting a spec file on the onboarding API. Alternatively, an Acumos
 236 model can be onboarded using the Acumos Adapter. Once successfully
 237 onboarded, the genprocessor converts converts them to jars and onboards
 238 them into Nifi i.e DCAE MOD. These artifacts are now available to use
 239 from the Modified Nifi Web UI i.e DCAE Designer.
 240
 241 The registry api offers version control and retrieval for flows. The
 242 distributor api can be used to set distribution targets. Once a flow is
 243 designed and distributed, it goes to the distributor api which is
 244 supposed to post graph changes (in accordance with fbp) to the runtime
 245 api. The runtime api generates and distributes deployment artifacts (either
 246 blueprints or helm charts) based on the
 247 change made on the flow-graph. The generated blueprints are received by the DCAE
 248 inventory can then be viewed and deployed from the DCAE dashboard. On helm mode,
 249 charts generated are pushed into configured Chartmuseum registry.
 250
 251
 252
 253 .. |image0| image:: ../images/DCAE-Mod-Architecture.png
 254
 255 .. |image1| image:: ../images/Onboarding-with-DCAE-MOD.png
 256
 257 .. |image2| image:: ../images/nifi-toolbar-components.png
 258
 259 .. |image3| image:: ../images/128713731_image2022.png