summaryrefslogtreecommitdiffstats
path: root/docs/sections/architecture.rst
diff options
context:
space:
mode:
authorVijay VK <vv770d@att.com>2018-10-23 16:35:29 +0100
committerVENKATESH KUMAR <vv770d@att.com>2018-10-23 12:02:55 -0400
commit86cd893e8dbbbd02a1b3209baa6da60337ae417a (patch)
tree5d867dcc5dcfdeb46c79dbada9b30a0cb5ce9c53 /docs/sections/architecture.rst
parent2133aae7fd41c0d100dbc31ebb5ac2d5456fc15a (diff)
dcaegen2 doc updates
Change-Id: I8f0a8a733b6e28fc9d18bed81c9ac4e82c954af8 Signed-off-by: VENKATESH KUMAR <vv770d@att.com> Issue-ID: DCAEGEN2-573
Diffstat (limited to 'docs/sections/architecture.rst')
-rw-r--r--docs/sections/architecture.rst4
1 files changed, 2 insertions, 2 deletions
diff --git a/docs/sections/architecture.rst b/docs/sections/architecture.rst
index b1c00889..a53480b0 100644
--- a/docs/sections/architecture.rst
+++ b/docs/sections/architecture.rst
@@ -59,14 +59,14 @@ The figure below shows the DCAE R3 architecture and how the components work with
.. image:: images/R3_architecture_diagram.gif
-Note: PM-Mapper was descoped from R3
+Note: Missing Heartbeat, Universal Data-mapper, PM-Mapper descoped from R3
Deployment Scenarios
--------------------
Because DCAE service components are deployed on-demand following the control loop needs for managing ONAP deployed services, DCAE must support dynamic and on-demand deployment of service components based on ONAP control loop demands. This is why all other ONAP components are launched from the ONAP level method, DCAE only deploys a subset of its components during this ONAP deployment process and rest of DCAE components will be deployed either as TOSCA executor launches a series of Blueprints, or deployed by control loop request originated from CLAMP, or even by operator manually invoking DCAE's deployment API call.
-For R2, ONAP supports two deployment methodologies: Heat Orchestration Template method, or Helm Chart method. No matter which method, DCAE is deployed following the same flow. At its minimum, only the TOSCA model executor, the DCAE Cloudify Manager, needs to be deployed through the ONAP deployment process. Once the Cloudify Manager is up and running, all the rest of DCAE platform can be deployed by a bootstrap script, which makes a number of calls into the Cloudify Manager API with Blueprints for various DCAE components, first the DCAE Platform components, then the service components that are needed for the built-in control loops, such as vFW/vDNS traffic throttling. It is also possible that additional DCAE components are also launched as part of the ONAP deployment process using the ONAP level method instead of TOSCA model based method.
+For R3, ONAP supports two deployment methodologies: Heat Orchestration Template method, or Helm Chart method. No matter which method, DCAE is deployed following the same flow. At its minimum, only the TOSCA model executor, the DCAE Cloudify Manager, needs to be deployed through the ONAP deployment process. Once the Cloudify Manager is up and running, all the rest of DCAE platform can be deployed by a bootstrap script, which makes a number of calls into the Cloudify Manager API with Blueprints for various DCAE components, first the DCAE Platform components, then the service components that are needed for the built-in control loops, such as vFW/vDNS traffic throttling. It is also possible that additional DCAE components are also launched as part of the ONAP deployment process using the ONAP level method instead of TOSCA model based method.
More details of the DCAE R3 deployment will be covered by the Installation section.