DRAFT PROPOSAL FOR COMMENTS
The content of this template is expected to be fill out for M1 Release Planning Milestone.
...
| Project Name | Enter the name of the project |
|---|---|
| Target Release Name | R1 Beijing Release |
| Project Lifecycle State | Incubation. Refer to ONAP Charter, section 3.3 Project Lifecycle for further information |
| Participating Company | AT&T, Intel, Huawei, Orange, TechM, IBM |
Scope
What is this release trying to address?
The scope of this release will be for the Portal Platform to support the approved use cases below list for R1 Beijing.
- Platform Maturity Guidelines (Highest Priority)
- Integrating with MUSIC, OOM, and AAF
- 50% JUnit Test Coverage
- Addressing security issues
- Bootstrapping of VID roles and tighter integration with AAF (Medium Priority)
- Role Centralization capability for framework based partners - design related (Low Priority)
- Platform Enhancements - Improved logging, Security Hardening, and SDK Simplification (Low Priority)
Additionally, this release will also support the continued development of the Portal Framework Platform to support future functionality not required for R1 Beijing. This body of work will be of a lower priority to the work required to support the Use Cases for the Release.
...
Describe the use case this release is targeted for (better if the reference to customer use case).
...
Sub-components are repositories are consolidate in a single centralized place. Edit the Release Components name for your project in the centralized page.
...
AAF (Application Authorization Framework) - for role/user creation, authentication, authorization.
OOM
MUSIC
Architecture
High level architecture diagram
...
Anyone reading this section should have a good understanding of all the interacting modules.
View file name portal_arch.pdf height 250
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 | 0 | 1 |
|
| ||||||||||||||||||||||||
| Stability | 1 | 1 | CSIT tests shows the stability of the component - https://jenkins.onap.org/view/CSIT/job/portal-master-csit-testsuite/ |
| ||||||||||||||||||||||||
| Resiliency | 1 | 2 | Integrating with MUSIC
|
| ||||||||||||||||||||||||
| Security | 0 | 1 | >50% Test Coverage - https://sonar.onap.org/dashboard?id=org.onap.portal%253Aonap-portal-parent
|
| ||||||||||||||||||||||||
| Scalability | 0 | 1 | Integrating with MUSIC
|
| ||||||||||||||||||||||||
| Manageability | 1 | 1 |
|
| ||||||||||||||||||||||||
| Usability | 1 | 2 |
|
|
API Incoming Dependencies
List the API this release is expecting from other releases.
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.
| API Name | API Description | API Definition Date | API Delivery date | API Definition link (i.e.swagger) | |
|---|---|---|---|---|---|
| AAF | Restful APIs for fetching available roles to portal onboarded application users | TBD | TBDJan. 10 | Jan 31 | Link toward the detailed API description |
| AAF | Push Portal/VID roles to AAF | Jan 10 | Jan 31 | Link toward the detailed API description |
API Outgoing Dependencies
...
| API Name | API Description | API Definition Date | API Delivery date | API Definition link (i.e.swagger) | To fill out | High level description of the APIDate 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 |
|---|---|---|
| MariaDB | The MariaDB is the repository that holds |
| all the policies, templates, PDP group, and deployment information. | 10.0 | |
| Nexus | The Nexus repository holds all the currently deployed Operational (i.e. Drools policies) and their dependent artifacts. | 2.14.2-01 |
| ElasticSearch | Used to search text within policy. | 5.4.0 |
| Ubuntu | Operating system | 14.04 |
In case there are specific dependencies (Centos 7 vs Ubuntu 16. Etc.) list them as well.
...
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.
JUnit tests: 50% code coverage is the goal for all repositories.
If resources become available, we will add more CSIT test cases.
| Jira Legacy | ||||||
|---|---|---|---|---|---|---|
|
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.
...
| Jira Legacy | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
...
| Risk identified | Mitigation Plan | Contingency Plan | ||
|---|---|---|---|---|
| To fill out | To fill out | To fill outResources | Actively seeking community support. | Current resources are only enough to satisfy the Highest Priority Epics (Platform Maturity, JUnit 50% test coverage). But that will be difficult to achieve. |
Resources
Fill out the Resources Committed to the Release centralized page.
Release Milestone
...
The project team comply with the ONAP Charter.
Release Key Facts
Fill out and provide a link toward the centralized Release Artifacts.