...
What is this release trying to address?
- to integrate with AAF
- to make Holmes model driven
- to implement the S3P requirements
- to upgrade AAI APIs used by Holmes
Requirements
None.
Minimum Viable Product
- rules for CCVNP/VoLTE
- 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=Holmes and issuetype in (story) and fixVersion="Frankfurt Release" serverId 425b2b0a-557c-3c0c-b515-579789cceedb
Longer term roadmap
- better integration with CLAMP
- 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.
...
High level architecture diagram
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 three main sub-modules: the rule management module, the engine management module and the data source adapter. 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 data source adapter is used as the data format converter between Holmes and other components. The module diagram is like below:
Platform Maturity
Please fill out the centralized wiki page: Frankfurt Release Platform Maturity
...
Testing and Integration Plans
- For unit tests, we are going to keep the line coverage of each module to be above 50% or even higher.
- For the functional tests, because there will be few functional requirements for Holmes, we will main reuse the current auto testing scripts to promise that the basic functions of Holmes work well. As for the GUI part, we will add some new test cases onto the wiki page and attach the corresponding testing report to it.
- For the non-functional requirements, we will set up a set of testing env and get them tested by ourselves. Meanwhile, we'll be collaborating with the integration team to get some advice on how to get all those platform maturity requirement tested.
Gaps
This section is used to document a limitation on a functionality or platform support. We are currently aware of this limitation and it will be delivered in a future Release.
List identified release gaps (if any), and its impact.
...