...
| Project Name | Enter the name of the project |
|---|---|
| Target Release Name | Beijing |
| Project Lifecycle State | Incubation Refer to ONAP Charter, section 3.3 Project Lifecycle for further information |
| Participating Company | AT&T, Amdocs, Huawei, Nokia, China Mobile, Orange, ZTE, Accenture |
...
What is this release trying to address?
- Update project-level documentation for Beijing Release requirements
- Improving the Usability of the Platform:
- Establish consistent tool chain and
...
- guidelines for API documentation
- Create
...
- Welcome to ONAP and "sandbox" functionality for novices to ONAP
...
- Automate verification process in the CI/CD Documentation tool chain
...
- Migrate seed documentation currently in the wiki or gerrit that is being maintained by approved projects
- Refine / expand current documentation for VNFs, OpenStack interfaces, UIs, and LF Tool Chain
- Establish feedback mechanisms in Wiki and/or Readthedocs to improve documentation
Use Cases
The documentation created by this project must support ONAP high level Beijing use cases.
Lower level use cases specific to documentation project scope include:
- Store documentation source in gerrit project repositories in a form that is easy for multiple authors to create and maintain.
- Define and integrate source from multiple repository locations into an complete, organized set for an ONAP release.
- Automatically (re)create a complete set of finished documentation whenever any sources change.
- Publish the finished set of documentation in where it can be easily referenced by any user audience that is working with an ONAP release.Publish a finished set of formal change-controlled documentation for any user audience working with the ONAP Beijing release.
- Establish a consistent method for documenting APIs
- Create welcoming documentation and a place to play for novices to ONAP
- Create a way for users to provide feedback
Minimum Viable Product
Final documentation for ONAP Release 2 Beijing Use Cases
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 Legacy server System Jira columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution maximumIssues 20 jqlQuery projectProject = sanbox and issuetype in (epic) serverId 4733707d-2057-3a0f-ae5e-4fd8aff50176
Stories
Jira Legacy server System Jira columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution maximumIssues 20 jqlQuery project=sanbox and issuetype in (story) Doc and type = EPIC and status = Open serverId 4733707d-2057-3a0f-ae5e-4fd8aff50176
Stories
Longer term roadmap
Indicate at a high level the longer term roadmap. This is to put things into the big perspective.
...
Indicate the outcome (Executable, Source Code, Library, API description, Tool, Documentation, Release Note...) of this release.
| Required (Level 1) | Deliverable Description |
|---|---|
| doc | Source Repository with a master index for all documentation in an ONAP Release in TBD( .rst, .md, or other) format. |
| doc/tools | Scripts used to collect, compose, validate source documentation material and publish final form documentation |
| doc/source/<repository> | Repositories as needed to
|
| TBD (onap.readthedocs.io, nexus.onap.org raw site) | Published release documentation |
| Beijing Project-level Updates | Published release documentation for all Beijing projects |
| Stretch Goals (Level 2) | Deliverable Description |
| Content Initiatives |
|
| Tool Chain Initiatives |
|
Sub-Components
List all sub-components part of this release.
Activities related to sub-components must be in sync with the overall release.
Sub-components are repositories and are consolidated in a single centralized place. Edit the Release Components name for your project in the centralized page.
...
Anyone reading this section should have a good understanding of all the interacting modules.Gliffy
The diagram below illustrates what is accomplished in the setup steps above from the perspective of a file structure created for a local test, a jenkins verify job, and/or published release documentation including:
...
| Area | Actual Level | Targeted Level for current Release | How, Evidences | Comments |
|---|---|---|---|---|
| Performance | N/A | N/A |
| |
| Stability | N/A | N/A |
| |
| Resiliency | N/A | N/A |
| |
| Security | N/A | N/A |
| |
| Scalability | N/A | N/A |
| |
| Manageability | N/A | N/A |
| |
| Usability | 1 | 1 | Usability Initiatives for Beijing (Release 2) |
|
...
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.
| 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 descriptionN/A |
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 API | Date for which the API is reviewed and agreed | To fill out | Link toward the detailed API description |
| N/A |
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 outN/A |
In case there are specific dependencies (Centos 7 vs Ubuntu 16. Etc.) list them as well.
...
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.
| Gaps identified | Impact |
|---|---|
| To fill out | To fill out |
| N/A |
Known Defects and Issues
Provide a link toward the list of all known project bugs.
| Jira Legacy | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
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).
| Risk identified | Mitigation Plan | Contingency Plan | ||
|---|---|---|---|---|
| Scope of release requirements | Complete and Interlock on Release Index | To fill out | ||
| Availability of contributors | Create/Link JIRA Contribution Stories to | Alignment on the Minimum Viable Tool Chain | Create early, partial content, end to end exampleRecruit resources as needed | Adjust scope & deliverables accordingly |
Resources
Fill out the Resources Committed to the Release centralized page.
Release Milestone
The milestones are defined at the Release Level and all the supporting project agreed to comply with these dates.
...