CCSDK : Dublin: Release Planning

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.
Use the Wiki to document the release plan. Don't provide PowerPoint.
Use as much diagrams and flow charts as you need, directly in the wiki, to convey your message.


Overview

Project Name

Enter the name of the project

Project Name

Enter the name of the project

Target Release Name

Dublin

Project Lifecycle State

Incubation

Participating Company 

AMDOCS, AT&T, Bell Canada, Ericsson,Huawei, IBM, Tech Mahendra

Scope

What is this release trying to address?

The primary focus of the ONAP release 4 (Dublin) is to advance platform maturity, with a focus on S3P (Scalabllity, Stability, Security and Performance).

Use Cases

CCSDK will support the following use cases from previous releases:

  • vFW

  • vDNS

  • vCPE

  • VoLTE

  • CCVPN

CCSDK will also support the following additional use cases for Dublin:

  • 5G

Minimum Viable Product

The following epics represent the minimum viable product for the Dublin CCSDK release:

key summary type created updated due assignee reporter priority status resolution
Loading...
Refresh

The following epics represent stretch goals for the Dublin CCSDK release.  These are currently planned for part of the release, but might be scaled back or deferred if necessary due to resource constraints.

key summary type created updated due assignee reporter priority status resolution
Loading...
Refresh

Functionalities

Epics

The following epics are committed for the Dublin release

key summary type created updated due assignee reporter priority status resolution
Loading...
Refresh

The following epics are considered stretch goals for the Dublin release.  These are currently planned, but might scaled back or cut if necessary due to resource constraints.

key summary type created updated due assignee reporter priority status resolution
Loading...
Refresh

Stories

The following stories are currently planned for the Dublin release.

key summary type created updated due assignee reporter priority status resolution
Loading...
Refresh

Longer term roadmap

Indicate at a high level the longer term roadmap. This is to put things into the big perspective.

Release Deliverables

Indicate the outcome (Executable, Source Code, Library, API description, Tool, Documentation, Release Note...) of this release.





Deliverable Name

Deliverable Description

Deliverable Location

Deliverable Name

Deliverable Description

Deliverable Location

CCSDK Source Code

Source code for CCSDK project

ONAP gerrit

CCSDK Maven Artifacts

Compiled code that can be referenced in other projects as maven dependencies

ONAP Nexus

CCSDK Docker Containers

Docker containers associated with SDNC project:

  • Controller (OpenDaylight) container

  • Database container

  • Directed Graph Builder container

ONAP Nexus

Documentation

User and developer guides

ONAP Wiki

CCSDK CI/CD automation

Scripts to automate compilation and deployment of maven artifacts and docker containers

ONAP gerrit

ONAP Jenkins

Sub-Components

Subcomponents of each ONAP project may be found on the Resources and Repositories (Deprecated) page on this wiki.  Please see the CCSDK section of that page for subcomponent list of CCSDK.



Architecture

High level architecture diagram

CCSDK will be delivered as a set of libraries accessible as Maven dependencies, as well as a set of base Docker containers. The docker containers themselves are intended to be used by other projects as a basis for their own controller-specific docker containers.

The following diagram illustrates how CCSDK is used by the controller projects:



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

Area

Actual Level

Targeted Level for current Release

How, Evidences

Comments

Performance

0

0

Awaiting guidance from Benchmark subcommittee

  • 0 -- none

  • 1 – baseline performance criteria identified and measured

  • 2 & 3 – performance improvement plans created & implemented

Stability

0

N/A

As a project that provides a library framework, CCSDK has no standalone component that can be soaked

  • 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

Resiliency

1

2

While CCSDK itself has no standalone component, it does provide an OpenDaylight docker container used by SDNC and APPC. In Beijing, CCSDK will support a clustered OpenDaylight configuration in Kubernetes, as well as a clustered database, to allow for automated detection and recovery within a site.

  • 0 – none

  • 1 – manual failure and recovery (< 30 minutes)

  • 2 – automated detection and recovery (single site)

  • 3 – automated detection and recovery (geo redundancy)

Security

0

1

CCSDK will achieve 50% code coverage

  • 0 – none

  • 1 – CII Passing badge + 50% Test Coverage + 50% test coverage

  • 2 – CII Silver badge; internal communication encrypted; role-based access control and authorization for all calls

  • 3 – CII Gold

Scalability

0

N/A

Scaling does not apply to CCSDK itself, as a set of libraries.

  • 0 – no ability to scale

  • 1 – single site horizontal scaling

  • 2 – geographic scaling

  • 3 – scaling across multiple ONAP instances

Manageability

1

1

CCSDK will support ONAP standard logging.

  • 1 – single logging system across components; instantiation in < 1 hour

  • 2 – ability to upgrade a single component; tracing across components; externalized configuration management

Usability

1

1

See readthedocs and wiki.

  • 1 – user guide; deployment documentation; API documentation

  • 2 – UI consistency; usability testing; tutorial documentation



API Incoming Dependencies

API Name

API Description

API Definition Date

API Delivery date

API Definition link (i.e.swagger)

API Name

API Description

API Definition Date

API Delivery date

API Definition link (i.e.swagger)

A&AI : schemas

A&AI schemas used by CCSDK aaa-service module

Defined in seed code

Included in seed code

TBD

SDC : distribution client

API used by ueb-listener (in CCSDK sdnc-northbound repo) to receive artifacts from SDC

Defined in seed code

Included in seed code

TBD



API Outgoing Dependencies



API Name

API Description

API Definition Date

API Delivery date

API Definition link (i.e.swagger)

API Name

API Description

API Definition Date

API Delivery date

API Definition link (i.e.swagger)

Maven libraries

Libraries used as dependencies by SDN-C, APP-C, DCAE and OOM

Included in seed code

Delivered in seed code

Javadoc will be provided

Docker containers

Base docker containers will be provided which can be used by SDN-C and APP-C as a basis for their docker containers

Included in seed code

Delivered in seed code



Third Party Products Dependencies

Name

Description

Version

Name

Description

Version

OpenDaylight

OpenDaylight SDN Controller Platform

Fluorine



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.

Gaps identified

Impact

Gaps identified

Impact

To fill out

To fill out

Known Defects and Issues

Provide a link toward the list of all known project bugs.

key summary type created updated due assignee reporter priority status resolution
Loading...
Refresh

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

Risk identified

Mitigation Plan

Contingency Plan

To fill out

To fill out

To fill out

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.

Team Internal Milestone

The following table shows the major project milestones and intermediate milestones for the Dublin release. 



Milestone

Description 

Date

Comments

Milestone

Description 

Date

Comments

M1

End of release planning



Formal commitment to release scope



  • M1 worksheets ready for review

Jan 22, 2019

Release manager reviews worksheets to assess readiness for M1 milestone



  • TSC M1 approval vote

Jan 24, 2019



M2

Functionality Freeze







  • Stable user stories baselined

Feb 15, 2019





  • M2 worksheets ready for review

Feb 19, 2019

Release manager reviews worksheets to assess readiness for M2 milestone



  • TSC M2 approval vote

Feb 21, 2019



M3

API Freeze







  • Final API definitions (swagger, Yang) due

March 8, 2019

Last day to submit Dublin swagger / Yang changes to Gerrit



  • M3 worksheets ready for review

March 12, 2019

Release manager reviews worksheets to assess readiness for M3 milestone



  • TSC M3 approval vote

March 14, 2019



M4

Code Freeze







  • Code due for Dublin user stories

March 29, 2019

Last day to submit Dublin code changes to Gerrit



  • M4 worksheets ready for review

April 2, 2019

Release manager reviews worksheets to assess readiness for M4 milestone, including the following checks:

  • All repos must have >= 50% code (line) coverage in Sonar

  • No failed Jenkins jobs

  • All CSIT tests pass

  • Healthchecks pass



  • TSC M4 approval vote

April 4, 2019



RC0

Release Candidate 0







  • Code due for RC0 fixes

April 19, 2019

Last date to submit code fixes for release candidate 0



  • RC0 release artifacts available

April 23, 2019





  • RC0 worksheets ready for review

April 23, 2019





  • TSC RC0 approval vote

April 25, 2019



RC1

Release Candidate 1







  • Code due for RC1 fixes

May 3, 2019

Last date to submit code fixes for release candidate 1



  • RC1 release artifacts available

May 7, 2019





  • RC1 worksheets ready for review

May 7, 2019





  • TSC RC1

May 9, 2019



RC2

Release Candidate 2







  • Code due for final Dublin fixes

May 17, 2019

Last date to submit code fixes for final Dublin release (RC2)



  • RC2 release artifacts available

May 21, 2019





  • RC2 worksheets ready for review

May 21, 2019





  • TSC RC2

May 23, 2019



Release Sign-Off

Final TSC Sign-Off

May 30, 2019

Dublin Release Sign-Off



Documentation, Training

  • Highlight the team contributions to the specific document related to he project (Config guide, installation guide...).

  • Highlight the team contributions to the overall Release Documentation and training asset

  • High level list of documentation, training and tutorials necessary to understand the release capabilities, configuration and operation.

  • Documentation includes items such as:

    • Installation instructions

    • Configuration instructions

    • Developer guide

    • End User guide

    • Admin guide

    • ...

Note

The Documentation project will provide the Documentation Tool Chain to edit, configure, store and publish all Documentation asset.


Other Information

  • Vendor Neutral

If this project is coming from an existing proprietary codebase, ensure that all proprietary trademarks, logos, product names, etc. have been removed. All ONAP deliverables must comply with this rule and be agnostic of any proprietary symbols.

  • Free and Open Source Software

FOSS activities are critical to the delivery of the whole 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.

Each project must edit its project table available at Project FOSS.



Charter Compliance

The project team comply with the ONAP Charter.