Versions Compared

Old Version 4

changes.mady.by.user Gregory Glover

Saved on

compared with

New Version Current

changes.mady.by.user Gregory Glover

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Project NameEnter the name of the project
Target Release NameEnter the name of the release you are targeting to deliverBeijing
Project Lifecycle StateEither 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, Amdocs, Huawei, Nokia, China Mobile, Orange, ZTE, Accenture

Scope

What is this release trying to address?

...

  1. Update project-level documentation for Beijing Release requirements
  2. 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 new documentation created by this project must support ONAP high level Amsterdam Beijing use cases.

Lower level use cases specific to documentation project scope include:

  1. Store documentation source in gerrit project  repositories in a form that is easy for multiple authors to create and maintain.
  2. Define and integrate source from multiple repository locations into an complete, organized set for an ONAP release.
  3. Automatically (re)create a complete set of finished documentation whenever any sources change.
  4. Publish the finished set of documentation in where it can be easily referenced by any user audience that is working with an ONAP release.
  1. Publish a finished set of formal change-controlled documentation for any user audience working with the ONAP Beijing release.
  2. Establish a consistent method for documenting APIs
  3. Create welcoming documentation and a place to play for novices to ONAP
  4. Create a way for users to provide feedback

Minimum Viable Product

Final documentation for ONAP Release 1 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
serverONAP JIRA
columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
maximumIssues20
jqlQueryprojectProject = sanbox and issuetype in (epic)
serverId425b2b0a-557c-3c0c-b515-579789cceedb

Stories

Jira
serverONAP JIRA
columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
maximumIssues20
jqlQueryproject=sanbox and issuetype in (story) Doc and type = EPIC and status = Open
serverId425b2b0a-557c-3c0c-b515-579789cceedb

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.
Each index file may contain source content and references to other index files within the doc repo directory structure, other repositories with the doc project (eg. doc/source/userguide), and/or other project repositories.

doc/toolsScripts used to collect, compose, validate source documentation material and publish final form documentation
doc/source/<repository>

Repositories as needed to

  • store content that integrates documentation across the platform and/or focuses on users audiences and tasks that a software project does not need to be aware of (eg. a task that uses multiple software components)
  • reflect different committer expertise and responsibility for a class of documentation (eg. guide for a developer, user, operations)
Beijing Project-level UpdatesPublished release documentation for all Beijing projects
Stretch Goals (Level 2)Deliverable Description
Content Initiatives
  • Published Guidelines for API documentation
  • Published "Welcome to ONAP" and "sandbox" functionality
  • Migrated seed documentation currently in the wiki or gerrit
  • Refined / expanded documentation for VNFs, OpenStack interfaces, UIs, and LF Tool Chain
Tool Chain Initiatives
  • Tool Chain established for API documentation
  • Refined and hardened CI/CD tool chain and processes
  • Feedback mechanisms implemented in Wiki and/or Readthedocs
TBD (onap.readthedocs.io, nexus.onap.org raw site)Published release documentation

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 DiagramnameDOC Architecture for M1




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:

...

AreaActual LevelTargeted Level for current ReleaseHow, EvidencesComments
PerformanceN/AN/A
  • 0 -- none
  • 1 – baseline performance criteria identified and measured
  • 2 & 3 – performance improvement plans created & implemented
Stability

N/A


N/A
  • 0 – none
  • 1 – 72 hours component level soak w/random transactions
  • 2 – 72 hours platform level soak w/random transactions
  • 3 – 6 months track record of reduced defect rate
ResiliencyN/AN/A
  • 0 – none
  • 1 – manual failure and recovery (< 30 minutes)
  • 2 – automated detection and recovery (single site)
  • 3 – automated detection and recovery (geo redundancy)
SecurityN/AN/A
  • 0 – none
  • 1 – CII Passing badge + 50% Test Coverage
  • 2 – CII Silver badge; internal communication encrypted; role-based access control and authorization for all calls
  • 3 – CII Gold
ScalabilityN/AN/A
  • 0 – no ability to scale
  • 1 – single site horizontal scaling
  • 2 – geographic scaling
  • 3 – scaling across multiple ONAP instances
ManageabilityN/AN/A
  • 1 – single logging system across components; instantiation in < 1 hour
  • 2 – ability to upgrade a single component; tracing across components; externalized configuration management
Usability11Usability Initiatives for Beijing (Release 2)
  • 1 – user guide; deployment documentation; API documentation
  • 2 – UI consistency; usability testing; tutorial documentation

...

API NameAPI DescriptionAPI Definition DateAPI Delivery dateAPI Definition link (i.e.swagger)
To fill outHigh level description of the APIDate for which the API is reviewed and agreedTo fill outLink toward the detailed API description
N/A



  • API API Outgoing Dependencies

API this project is delivering to other projects.

API NameAPI DescriptionAPI Definition DateAPI Delivery dateAPI Definition link (i.e.swagger)
To fill outHigh level description of the APIDate for which the API is reviewed and agreedTo fill outLink 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, ...).

NameDescriptionVersion
To fill outTo fill outTo fill out
N/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 identifiedImpact
To fill outTo fill outN/A

  • Known Defects and Issues

Provide a link toward the list of all known project bugs. JiraserverONAP JIRAcolumnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutionmaximumIssues20jqlQueryproject=sanbox and issuetype in (bug) serverId425b2b0a-557c-3c0c-b515-579789cceedb



  • 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 identifiedMitigation PlanContingency Plan
Scope of release requirementsComplete and Interlock on Release IndexTo fill out
Availability of contributorsCreate/Link JIRA Contribution Stories toRecruit resources as neededAdjust scope & deliverables accordinglyAlignment on the Minimum Viable Tool ChainCreate early, partial content, end to end  example

  • 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.

...