diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/platform/architecture.rst | 2 | ||||
| -rw-r--r-- | docs/platform/configuration.rst | 2 | ||||
| -rw-r--r-- | docs/platform/delivery.rst | 4 | ||||
| -rw-r--r-- | docs/platform/human-interfaces.rst | 2 | ||||
| -rw-r--r-- | docs/platform/log-and-diagnostic-info.rst | 2 | ||||
| -rw-r--r-- | docs/release-notes.rst | 57 |
6 files changed, 57 insertions, 12 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 ^^^^^^^^^^^^^^^^^^^^^^^^^^^ diff --git a/docs/release-notes.rst b/docs/release-notes.rst index 2845e4b..35c1a32 100644 --- a/docs/release-notes.rst +++ b/docs/release-notes.rst @@ -14,18 +14,22 @@ ocean of events collected from different levels of the telecom cloud. Version: 1.1.0 -------------- -:Release Date: 2018-05-24 +:Release Date: 2018-06-07 **New Features** -In the Amsterdam release, Holmes is mainly intended to support the alarm -correlation analysis for the VoLTE scenario. To get us there, Holmes provides -the following features: +In the Beijing release, Holmes provides no more functionalites than the Amsterdam release. Its main features remains like follows: - `Rule Management <https://jira.onap.org/browse/HOLMES-4>`_ The feature provides interfaces for the users to create, query, update and delete rules. In this release, they are used along with the DCAE interfaces to accomplish the deployment (creation/update) of the control loop related rules. - `Engine Management <https://jira.onap.org/browse/HOLMES-5>`_ The feature is not exposed to the end user directly. It's mainly used internally by Holmes as a container for the execution of rules. It provides interface for rule verification and deployment/un-deployment. +Besides, Holmes has been enhanced to meet the platform maturity requirements. The enhancement mainly covers: + +- Scaling: Holmes supports horizontal scale-in/scale-out operations in case it is overloaded by too large amounts of data. + +- Security: Holmes has updated all its APIs to support the HTTPS protocol. + **Bug Fixes** N/A @@ -37,7 +41,14 @@ N/A **Security Issues** -Holmes is following the CII Best Practices Badge program. Most of its vulnerability issues have been fixed in Beijing Release except for the issues brought in by jackson-databind which is introduced indirectly by third-party dependencies (namely Dropwizard). The impact analysis can be found at `Holmes Security/Vulnerability Threat Impact Analysis <https://wiki.onap.org/pages/viewpage.action?pageId=28378012>`_ +HOLMES code has been formally scanned during build time using NexusIQ and all Critical vulnerabilities have been addressed, items that remain open have been assessed for risk and determined to be false positive. The HOLMES open Critical security vulnerabilities and their risk assessment have been documented as part of the `project <https://wiki.onap.org/pages/viewpage.action?pageId=28378012>`_. + +Quick Links: + - `HOLMES project page <https://wiki.onap.org/display/DW/Holmes+Project>`_ + + - `Passing Badge information for HOLMES <https://bestpractices.coreinfrastructure.org/en/projects/1602>`_ + + - `Project Vulnerability Review Table for HOLMES <https://wiki.onap.org/pages/viewpage.action?pageId=28378012>`_ **Upgrade Notes** @@ -51,7 +62,8 @@ Holmes is following the CII Best Practices Badge program. Most of its vulnerabil **Deprecation Notes** -N/A +None of the HTTP APIs provided in the Amsterdam release are available in Beijing anymore. + **Other** @@ -59,4 +71,37 @@ N/A =========== +Version: 1.0.0 +-------------- + +:Release Date: 2017-11-16 + + +**New Features** +In the Amsterdam release, Holmes is mainly intended to support the alarm +correlation analysis for the VoLTE scenario. To get us there, Holmes provides +the following features: + +- `Rule Management <https://jira.onap.org/browse/HOLMES-4>`_ The feature provides interfaces for the users to create, query, update and delete rules. In this release, they are used along with the DCAE interfaces to accomplish the deployment (creation/update) of the control loop related rules. + +- `Engine Management <https://jira.onap.org/browse/HOLMES-5>`_ The feature is not exposed to the end user directly. It's mainly used internally by Holmes as a container for the execution of rules. It provides interface for rule verification and deployment/un-deployment. + +**Bug Fixes** + +This is the initial release. + +**Known Issues** + +If the database is not stable, there may be data/status inconsistency between the rule management module and the engine management module. + +**Security Issues** + +N/A + +**Upgrade Notes** + +This is the inital release. +=========== + + End of Release Notes |