...
| Project Name | Enter the name of the project |
|---|---|
| Target Release Name | Enter the name of the release you are targeting to deliver |
| Project Lifecycle State | Either Incubation, Core, Mature. Refer to ONAP Charter, section 3.3 Project Lifecycle for details on Project Lifecyclefurther information |
| Participating Company | List the company participating in this release. At least 3-4 organizations, including an operator are recommended. |
...
Sub-components are repositories are consolidate in a single centralized place. Edit the repository table for your project.
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.
Block and sequence diagrams showing relation within the project as well as relation with external components are expected.
Anyone reading this section show have a good understanding of all the interacting modules.
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 Functionality 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) |
|---|---|---|---|---|
| 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 |
...
Describe the plan to integrate and test the release deliverables with the overall OPEN-O ONAP system.
Confirm that resources have been allocated to perform such activities.
The Release lifecycle accounts for an Testing and Integration Review where detailed plan are expected.
...
Projects must specify whether they plan to use Open-O ONAP CI infrastructure for system test. It is recommended to use the Open-O ONAP CI infrastructure unless there is some HW or SW resource that cannot be installed there. Projects running system test in external Labs are required to report system test results in a timely fashion after release creations, e.g., weekly, RC, and formal releases.
...
If this project is coming from an existing proprietary codebase, ensure that all proprietary trademarks, logos, product names, etc. have been removed. All OPEN-O ONAP deliverables must comply with this rule and be agnostic of any proprietary symbols.
...
FOSS activities are critical to the delivery of the whole OPEN-O ONAP initiative. The information may not be fully available at Release Planning, however to avoid late refactoring, it is critical to accomplish this task as early as possible.
List all third party Free and Open Source Software used within the release and provide License type (BSD, MIT, Apache, GNU GPL,... ).
In the case non Apache License are found inform immediately the TSC and the Release Manager and document your reasoning on why you believe we can use a non Apache version 2 license.
...
| Note | ||
|---|---|---|
| ||
It is expected all materials to be published directly either in the wiki or in OPEN-O ONAP website. Do not provide deliverable in PDF, powerpoint or word documents (these format are not easy to edit and lead to versioning issues). |
...