DRAFT PROPOSAL FOR COMMENTS
The content of this template is expected to be fill out for M1 Release Planning Milestone.
| Info | ||
|---|---|---|
| ||
Use the "Copy" and "Move" options (available under the ..., top right of this page) to duplicate this template into your project wiki. |
| Table of Contents | ||
|---|---|---|
|
Overview
| Project Name | Enter the name of the projectMUSIC |
|---|---|
| Target Release Name | Enter the name of the release you are targeting to deliverBeijing |
| Project Lifecycle State | Either Incubation, Core, Mature. Refer to ONAP Charter, section 3.3 Project Lifecycle for further information |
| Participating Company List the company participating in this release. At least 3-4 organizations, including an operator are recommended. | AT&T, Intel, Netcracker, Verizon, Windriver (in lexical order) |
Scope
What is this release trying to address?
Describe the problem being solved by this release
Use Cases
Describe the use case this release is targeted for (better if reference to customer use case).
Minimum Viable Product
Describe the MVP for this release.
Functionalities
This release of MUSIC provides a service with recipes that individual ONAP components and micro-service can use for state replication, consistency management and state ownership across geo-distributed sites. This is a crucial component enabling ONAP components to achieve geo-redundancy (platform-maturity resiliency level 3).
Use Cases
- Targeted goal for R2: OOF-Homing Optimizer (HAS) uses MUSIC for its state persistence (as a queue) and as a highly available distributed messaging service.
- Stretch goal for R2: ONAP Portal will use MUSIC to store its http session state across sites in a persistent manner.
Minimum Viable Product
MUSIC service that can serve the geo-redundancy needs of ONAP HAS and ONAP Portal while satisfying the platform maturity requirements for the Beijing release. For Beijing this will be run as internal services to both Portal and OOF.
FunctionalitiesList 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.
Epics
Jira server ONAP JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution maximumIssues 20 jqlQuery project=sanbox music and issuetype in (epic) serverId 425b2b0a-557c-3c0c-b515-579789cceedb
...
Jira server ONAP JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution maximumIssues 20 jqlQuery project=sanbox music and issuetype in (story) serverId 425b2b0a-557c-3c0c-b515-579789cceedb
Longer term roadmap
Indicate at a high level the longer term roadmap. This is to put things into the big perspective.In the long term we hope that MUSIC will be common, shared state-management system for all ONAP components and micro-services to manage geo-redundancy. For example, we envisage the use of MUSIC for multi-site state management in SO (to store Camunda state across sites), <SDN-C, AppC> (to store ODL related state across sites) , A&AI (to store its graph data) and most other ONAP components that need to manage state across sites. Further, we envision that these services will use the MUSIC recipes (mdbc, prom, musicCAS, musicQ) to achieve the goal of a multi-site active-active federated ONAP solution.
Release Deliverables
Indicate the outcome (Executable, Source Code, Library, API description, Tool, Documentation, Release Note...) of this release.
| Deliverable Name | Deliverable Description |
|---|---|
| To fill out | To fill out |
Sub-Components
List all sub-components part of this release.
Activities related to sub-components must be in sync with the overall release.
| Source code and REST API | The entire source code for the MUSIC service and the corresponding REST API to access it. |
| Compilation scripts | Script to generate the MUSIC war file that can be deployed in the Apache Tomcat webserver |
| Installation guide | Document that describes how MUSIC can be installed in containers |
| Tool description | Complete description of the inner workings of MUSIC and how it performs state management |
| Basic Benchmarks | Basic performance benchmarks for the MUSIC operations |
| API documentation | REST API documentation in Swagger |
| Test Cases | Junit test cases covering sufficient parts of MUSIC code |
Sub-Components
NA. Sub-components are repositories and are consolidated in a single centralized place. Edit the Release Components name for your project in the centralized page.
Architecture
High level architecture diagram
At that stage within the Release, the team is expected to provide more Architecture details describing how the functional modules are interacting.
Indicate where your project fit within the ONAP Archiecture diagram.
Block and sequence diagrams showing relation within the project as well as relation with external components are expected.
In this figure the ONAP components targeted for R2 are ONAP HAS and Portal (stretch goal).
MUSIC will be available as a common service like DMaap or AAF as shown in the red, oblong box below:
Anyone reading this section should have a good understanding of all the interacting modules.
Platform Maturity
Refering to CII Badging Security Program and Platform Maturity Requirements, fill out the table below by indicating the actual level , the targeted level for the current release and the evidences on how you plan to achieve the targeted level.
| Area | Actual Level | Targeted Level for current Release | How, Evidences | Comments |
|---|---|---|---|---|
| Performance | 1 | 1 | This file shows basic performance benchmarks performed for MUSIC on a 10 node cluster. |
|
| Stability | 1 | 1 | As shown in this file, our experimental runs were all over 1 hour. |
|
| Resiliency | 2 | 2 | Within each container we have scripts that will detect failure of MUSIC and restart it. However, if the entire container fails, we will need OOM to bring it up. |
|
| Security | 2 | 2 |
|
|
| Scalability | 1 | 1 | Among the MUSIC components [tomcat, zookeeper, cassandra], new MUSIC nodes with the tomcat and cassandra can be added seamlessly to scale the cluster (MUSIC itself is state-less). Zookeeper nodes ideally should not be scaled since there are major performance implications. However, this can be done with reconfiguration. |
|
| Manageability | 1 | 1 | Using EELF with logback as the logging provider. |
|
| Usability | 1 | 1 | Use SWAGGER for the REST API and Installation Docs. Will need to enhance and update the documentation. |
|
...
API Incoming Dependencies
List the API this project is expecting from other projects.
Prior to Release Planning review, Team Leads must agreed on the date by which the API will be fully defined. The API Delivery date must not be later than the release API Freeze date.
Prior to the delivery date, it is a good practice to organize an API review with the API consumers.
...
NA.
API API Outgoing Dependencies
API this project is delivering to other projects.
| API Name | API Description | API Definition Date | API Delivery date | API Definition link (i.e.swagger) | |||||
|---|---|---|---|---|---|---|---|---|---|
| MUSIC API | The REST API used to store state and manage access to it through a locking service. | TBD. | TBD. | Waiting for project approval. | To fill out | High level description of the API | Date for which the API is reviewed and agreed | To fill out | Link toward the detailed API description |
Third Party Products Dependencies
Third Party Products mean products that are mandatory to provide services for your components. Development of new functionality in third party product may or not be expected.
List the Third Party Products (OpenStack, ODL, RabbitMQ, ElasticSearch,Crystal Reports, ...).
| Name | Description | Version |
|---|---|---|
| To fill out | To fill out | To fill out |
In case there are specific dependencies (Centos 7 vs Ubuntu 16. Etc.) list them as well.
Testing and Integration Plans
Provide a description of the testing activities (unit test, functional test, automation,...) that will be performed by the team within the scope of this release.
Describe the plan to integrate and test the release deliverables within the overall ONAP system.
Confirm that resources have been allocated to perform such activities.
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.
...
Known Defects and Issues
Provide a link toward the list of all known project bugs.
| Jira | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
Risks
List the risks identified for this release along with the plan to prevent the risk to occur (mitigation) and the plan of action in the case the risk would materialized (contingency).
...
| Cassandra | Higly-available key-value store that will maintain state. | 3.2 |
| Zookeeper | Distributed coordination service used to provide the locking service for MUSIC. | 3.4.6 |
| Tomcat | Web-server that will host the MUSIC code and support the REST API. | 9 |
Testing and Integration Plans
The following type of tests will be ensured for MUSIC in this release:
- Unit tests: Junit test cases will be added incrementally as part of code delivery ensuring static code analysis as recommended by common SW delivery practices. MUSIC is written in Java, so coverage target percentage will be evaluated along project. Unit Tests will be automated (as part of the build), so that execution will happen before every MUSIC delivery. This includes writing test cases for the new components and those for the existing ones not yet covered under unit testing. A python based Unit Testing framework will be integrated into the project, binding all developers to start with Unit Tests when developing each module.
- Functional Test cases: MUSIC will be tested according to the functionality committed to the Beijing release with a specific focus on the functionality utilised by ONAP HAS and ONAP Portal for MUSIC-based state management.
- End to End Test cases: MUSIC will be integrated within the whole ONAP components architecture and dedicated set of E2E test cases will be setup. Purpose, scope and details on E2E testing will be planned/defined subsequently by working with the Integration team, and for the test cases in the scope of this release.
Gaps
None identified so far.
Known Defects and Issues
None identified so far.
Risks
None identified so far.
Resources
Udated
Resources
Fill out the Resources Committed to the Release centralized page.
Release Milestone
...