Versions Compared

Old Version 9

changes.mady.by.user Bhanu Ramesh

Saved on

compared with

New Version Current

changes.mady.by.user tom.o.neill@ericsson.com

Saved on

Key

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

DRAFT PROPOSAL FOR COMMENTS

The content of this template is expected to be fill out for M1 Release Planning Milestone.

Info
titleInfo

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.

Table of Contents
outlinetrue

Overview

Project NameEnter the name of the project
Target Release NameDublin
Project Lifecycle StateIncubation/Mature
Participating Company 

AT&T

Ericsson

Nokia

Scope

What is this release trying to address?

5G Use Case is the principal driver for the enhancements in this release.

DMaaP - Message Router

Upgrade Kafka to 1v1.1.1Data Router updates to support Bulk PM use cases

Support for Authenticated topics in MR

Add Scaling support for DMaaP MR

DMaaP support Support for multi-site applicationsDMaaP Provisioning via Bus Controllerapplications 

Add MirrorMaker to allow for message replication across Kafka clusters

DMaaP - Data Router

Data Router updates to support Bulk PM use cases

DMaaP - Bus Controller

DMaaP Provisioning via Bus Controller

Use Cases

Describe the use case this release is targeted for (better if reference to customer use case)The existing Casablanca use cases are still going to be supported. We also support 5G use case requirements.

Minimum Viable Product

...

Kafka is updated to 1.1.1

Kafka MirrorMaker support

Support for authenticated topics

Provisioning the mirrormaker using buscontroller

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
serverSystem Jira
columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
maximumIssues20
jqlQueryproject=DMAAP and issuetype in (epic) and status != Done fixVersion = "Dublin Release" ORDER BY priority DESC, updated DESC
serverId4733707d-2057-3a0f-ae5e-4fd8aff50176

...

Jira Legacy
serverSystem Jira
columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
maximumIssues20
jqlQueryproject=DMAAP and issuetype in (story) and status != Done fixVersion = "Dublin Release" ORDER BY priority DESC, updated DESC
serverId4733707d-2057-3a0f-ae5e-4fd8aff50176

...

Deliverable NameDeliverable Description
Docker imageCustom Kafka image and DMaaP images
Source CodeSource code of DMaaP
Release NoteRelease note of the release

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.

kafka AAF plugin

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.

Indicate where your project fit within the ONAP Archiecture diagram.

Block and sequence diagrams showing relation within the project as well as relation with external components are expected.

Anyone reading this section should have a good understanding of all the interacting modules.architecture.pngImage Added



Platform Maturity

...

AreaActual LevelTargeted Level for current ReleaseHow, Evidences

Minimum Levels (Dublin)

Comments
Performance11


  • Closed-loop projects:  Level 2
  • All other projects:  Level 0  (Stretch goal: Level 1)
  • 0 -- none
  • 1 – baseline performance criteria identified and measured
  • 2 & 3 – performance improvement plans created & implemented
Stability112


  • Level 2
  • 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
Resiliency22
  • Runtime Projects: Level 2 (stretch goal Level 3)
    • NOTE: For Dublin, the building blocks will be put in place for Level 3 geo-redundancy, and a few projects will pilot it
  • All other Projects: Level 1 (stretch goal Level 2)
  • 0 – none
  • 1 – manual failure and recovery (< 30 minutes)
  • 2 – automated detection and recovery (single site)
  • 3 – automated detection and recovery (geo redundancy)
Security1

1

(2 stretch)


  • Platform Level 2
  • Additional recommendations: 
    • All projects SHOULD migrate from the Jackson Data Processor packages to the GSON packages unless the Jackson dependency is inherited from an outside project such as ODL.

    • All projects SHOULD provide the ability to turn on and turn off Secure communication. Secure communication is on by default.

  • 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
Scalability11
  • Runtime Projects: Level 1 
    • NOTE: For Dublin, the building blocks will be put in place for Level 2 geographic scaling, and a few projects will pilot it
  • All other Projects: Level 0
  • 0 – no ability to scale
  • 1 – single site horizontal scaling
  • 2 – geographic scaling
  • 3 – scaling across multiple ONAP instances
Manageability112
  • All Projects: Level 2
  • Stretch Goal: Level 3
  • 1 – single logging system across components; instantiation in < 1 hour
  • 2 – ability to upgrade a single component; tracing across components; externalized configuration management
Usability11
  • All Projects: Level 2
  • Stretch Goal: External APIs also follow the Versioning Strategy
  • 1 – user guide; deployment documentation; API documentation
  • 2 – UI consistency; usability testing; tutorial documentation

...

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

...

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 API
DMaaP MR APIAPI used to create Topics ,publish a message,subscribe to a Topic etc.Date for which the API is reviewed and agreedTBDAPI documentation
DMaaP Buscontroller APIProvisioning API for management of Topics and FeedsDate for which the API is reviewed and agreedM2API documentation (ReadTheDocs)
DMaaP DataRouter APIAPI used to create feeds ,publish to this feed, subscribe to a feedDate for which the API is reviewed and agreed
To fill outLink toward the detailed API description
M2  API documentation


  • Third Party Products Dependencies

...

????
NameDescriptionVersion
AJSCJava services container3.0.6-oss10
KafkaDistributed messaging platform

?

01.111.01
Zoo KeeperCentralized service for maintaining configuration information3.4.610
SpringSpring Framework

1.4

DockerContainer engine

1.12

In case there are specific dependencies  (Centos 7 vs Ubuntu 16. Etc.) list them as well.

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

  1. Unit test: Unit tests has at least 50% code coverage.
  2. Functional test: Leverage the robot framework infrastructure to provide the functional test.
  3. Integration test: Support integration team to provide the end to end integration test.
  4. All the above should be automation tests run on the LF Jenkins Infrastructure.


  • 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
serverSystem Jira
columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
maximumIssues20
jqlQueryproject=DMAAP and issuetype in (bug) and status != Done and status != Closed and fixVersion = "Dublin Release"
serverId4733707d-2057-3a0f-ae5e-4fd8aff50176

...

Risk identifiedMitigation PlanContingency Plan
To fill outTo fill outTo fill out

  • Resources

Fill out the Resources Committed to the Release centralized page.

  • Release Milestone

...