summaryrefslogtreecommitdiffstats
path: root/docs/platform
diff options
context:
space:
mode:
Diffstat (limited to 'docs/platform')
-rw-r--r--docs/platform/architecture.rst2
-rw-r--r--docs/platform/configuration.rst2
-rw-r--r--docs/platform/delivery.rst4
-rw-r--r--docs/platform/human-interfaces.rst2
-rw-r--r--docs/platform/log-and-diagnostic-info.rst2
5 files changed, 6 insertions, 6 deletions
diff --git a/docs/platform/architecture.rst b/docs/platform/architecture.rst
index 8a852e9..351f7af 100644
--- a/docs/platform/architecture.rst
+++ b/docs/platform/architecture.rst
@@ -4,7 +4,7 @@
ONAP-level Architecture
^^^^^^^^^^^^^^^^^^^^^^^
-Basically, Holmes itself is an independent component in ONAP, which means it could be deployed as an ONAP-level component. In the Amsterdam release, Holmes is more generally a DCAE analytic application. It is deployed by DCAE and run as an analytic application on top of it. Also, it could be considered as a filter of the Policy component because it reduces the number of the input messages of Policy.
+Basically, Holmes itself is an independent component in ONAP, which means it could be deployed as an ONAP-level component. In the Beijing release, Holmes is more generally a DCAE analytic application. It is deployed by DCAE and run as an analytic application on top of it. Also, it could be considered as a filter of the Policy component because it reduces the number of the input messages of Policy.
.. image:: images/overall-architecture-in-onap.png
diff --git a/docs/platform/configuration.rst b/docs/platform/configuration.rst
index cedb443..919b07e 100644
--- a/docs/platform/configuration.rst
+++ b/docs/platform/configuration.rst
@@ -4,5 +4,5 @@
Configuration
-------------
-No machanism for customized configurtions is provided in the Amsterdam release. Such functionalities will be provided in the future if necessary.
+No machanism for customized configurtions is provided in the Beijing release. Such functionalities will be provided in the future if necessary.
diff --git a/docs/platform/delivery.rst b/docs/platform/delivery.rst
index 5b2a0b1..f65b36e 100644
--- a/docs/platform/delivery.rst
+++ b/docs/platform/delivery.rst
@@ -5,11 +5,11 @@ Delivery
--------
Describe how functions are packaged into run-time components. For some components a block diagram may be useful.
-As mentioned in the architecture chapter, Holmes mainly comprises three modules: the rule management module, the engine management module and the data source adapter. But due to the imperfect implemetation of the DCAE platform, the engine management module and the data source adapter are hosted in a single docker. From this point of view, Holmes in the Amsterdam release actually consists of two main modules.
+As mentioned in the architecture chapter, Holmes mainly comprises three modules: the rule management module, the engine management module and the data source adapter. But due to the imperfect implemetation of the DCAE platform, the engine management module and the data source adapter are hosted in a single docker. From this point of view, Holmes in the Beijing release actually consists of two main modules.
* Rule Management Docker: The main operations on the rules are performed in this module. The module provides CRUD operation interfaces and is reponsible of the persistence of the rules as well.
-* Engine Management Docker: The Drools rules are actually deployed into the Drools engine which is embedded within the engine management module. The analysis tasks are excuted in this module as well. Ideally, the data source adapter is supposed to be running as a standalone docker and communicate with the engine management module via MQ (or any other message bus). But in the Amsterdam release, due to the limitation of the DCAE platform. These two modules are merged into one and interact with each other directy in the manner of Java API calls.
+* Engine Management Docker: The Drools rules are actually deployed into the Drools engine which is embedded within the engine management module. The analysis tasks are excuted in this module as well. Ideally, the data source adapter is supposed to be running as a standalone docker and communicate with the engine management module via MQ (or any other message bus). But in the Beijing release, due to the limitation of the DCAE platform. These two modules are merged into one and interact with each other directy in the manner of Java API calls.
* Common Library: The library hosts some supportive tools for both the rule management module and the engine management module. It is not run separately. Instead, it is introduced into the main modules of Holmes during the compile and package phase.
diff --git a/docs/platform/human-interfaces.rst b/docs/platform/human-interfaces.rst
index d73c6cc..4021206 100644
--- a/docs/platform/human-interfaces.rst
+++ b/docs/platform/human-interfaces.rst
@@ -7,7 +7,7 @@ Human Interfaces
Target Users
^^^^^^^^^^^^
-The human interfaces provided in the Amsterdam release by Holmes is intended for the developers rather than the end users.
+The human interfaces provided in the Beijing release by Holmes is intended for the developers rather than the end users.
Interface Type
^^^^^^^^^^^^^^
diff --git a/docs/platform/log-and-diagnostic-info.rst b/docs/platform/log-and-diagnostic-info.rst
index 53527f5..74c53db 100644
--- a/docs/platform/log-and-diagnostic-info.rst
+++ b/docs/platform/log-and-diagnostic-info.rst
@@ -4,7 +4,7 @@
Logging & Diagnostic Information
---------------------------------
-In the Amsterdam release, the logs are kept inside the docekr containers, which means that you can get the log information only when the docker is still running.
+In the Beijing release, the logs are kept inside the docekr containers, which means that you can get the log information only when the docker is still running.
Where to Access Information
^^^^^^^^^^^^^^^^^^^^^^^^^^^