...
Project Name | Enter the name of the project |
---|---|
Target Release Name | GuilinHonolulu |
Project Lifecycle State | Incubation |
Participating Company | ZTE, CMCC, HUAWEI, Fujitsu |
...
What is this release trying to address?
Basic Goals:
- to migrate from DCAE deployment to OOM deployment
- to optimize the way of AAI API invocation
- to upgrade AAI APIs used by Holmes
Stretched Goals:
- to make Holmes model-driven
- to implement the S3P requirements
- to integrate with AAF
Requirements
Describe the use case this release is targeted for (better if reference to customer requirements).
Minimum Viable Product
- rules for CCVNP/VoLTE/MDONS
- the rule management component
- the engine management component
Functionalities
List the functionalities that this release is committing to deliver by providing a link to JIRA Epics and Stories. In the JIRA Priority field, specify the priority (either High, Medium, Low). The priority will be used in case de-scoping is required. Don't assign High priority to all functionalities.
...
Jira server ONAP JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution maximumIssues 20 jqlQuery project=sanbox and issuetype in (story) serverId 425b2b0a-557c-3c0c-b515-579789cceedb
Longer term roadmap
...
- integration with Acumos
- integration with ORAN
Release Deliverables
Indicate the outcome (Executable, Source Code, Library, API description, Tool, Documentation, Release Note, etc) of this release.
Deliverable Name | Deliverable Description |
---|
API description | A brief introduction of the APIs of Holmes. Both external and internal users (systems) could implement alarm analyses using these APIs |
Documentation | Installation manual, user guide, etc. Please refer to Guilin Documentation. |
Release Notes | Release notes of the release |
Source Code | The source code of the sub-components listed below. |
Sub-Components
List all sub-components part of this release.
Activities related to sub-components must be in sync with the overall release.
...
Anyone reading this section should have a good understanding of all the interacting modules.
Holmes is architecturally an analytics application reside within DCAE.
Normally, it is deployed by DCAE. But if users want to use Holmes independently (without DCAE), it could also be deployed in a standalone mode in the form of ordinary docker containers.
The interaction diagram between Holmes and its relative components is depicted below:
Holmes itself consists of two basic sub-modules: the rule management module and the engine management module. The rule management module is mainly responsible for the CRUD operations of Holmes rules and persisting the rules into a database. The engine management module uses the Drools engine as its core component to support correlation analysis among alarms. The module diagram is like below:
Platform Maturity
...