Roadmap ¶
Table of Contents ¶
Overview ¶
-
The activities of the CNTT community are articulated around Projects , Milestones and Releases .
-
CNTT is embracing simultaneous delivery model, meaning that all contributing projects have to follow the cadence and intermediate milestones.
-
Each CNTT release is the only delivery vehicle and is common for all projects.
-
The CNTT current release plan is available here .
Figure 1: Milestones
Definitions
A project is:
-
Long term endeavour setup to deliver features across multiple releases as shown here
-
Led by leads/co-leads, contributors and committers with expertise in the relevant areas
-
Scripted and documented in repositories
A Release is:
-
Short term endeavour setup to deliver a specific features/functionalities as shown here .
-
An agreed common framework (template, criteria, best practice) for all projects
-
An unique release planning calendar with pre-defined milestones for each project
-
A vehicle to coordinate multiple projects and multiple type of projects (reference model and architecture, documentation, integration, packaging, deployment)
A Bundle is: A set of related specifications that are built to complement each other, specifically (RM -> RA -> RC -> RI).
A Version:
-
Each document within a release has a number attached to it that consists of Bundle.Version :
-
Bundle : specifies the bundle number of which the the document belongs to.
-
Version : specifies the sequential version of each document (improvement or enhancements).
-
-
Any Change in RM that will impact RAs and consequently RC and RI will triggers a new Bundle number.
Roadmap ¶
High Level Roadmap ¶
Figure 2: CNTT Technical Specification Roadmap
Detailed Roadmap ¶
Please refer to individual release plans and features for detailed roadmap.
Detailed Milestones ¶
|
Review |
Milestone |
Description |
Activities |
Comments |
|---|---|---|---|---|
|
Kick-Off |
M0 |
The goal of the release Kick-Off is to open the innovation platform for the intent to participate in the CNTT release. Release Kick-Off review takes place for each releases. |
Name the Release and create appropriate labels in GitHub. |
|
|
Planning & Scoping |
The goal of the Release Planning & Scoping is to capture the initial set of features and f unctionality that should be part of the release along with pri oritisation. |
Identity a list of features and f unctionality including from the backlog will be developed and documented as part of the current release. N.B. Feature/fu nctionality, errors etc. are logged in GitHub as Issues. Identify what is in or out of scope for the release. Escalate any issues to the TSC. |
||
|
Release Plan Review |
M1 |
The goal of the Release Planning review is to ensure the plan is complete, sufficient, and aligned with release milestones. All people resources are identified, documented and committed. |
After the review cut-off date any major features & fun ctionalities changes will be added to the backlog unless it is approved by the TSC to be added into the current scope of release. Bug fixes or any minor changes identified during the development will be allowed. For any other content changes to be approved by TSC. |
|
|
Scope Cha nges/Logging |
Feature/F unctionality changes to be part of current Release |
Feature/F unctionality changes (in Github) for the current scope of release. Project leads ensure feature/f unctionality are correctly labelled, mapped to the c orresponding project and milestone, etc. |
||
|
Scope Freeze |
M2 |
The goal of the Scope Freeze is to mark the end of adding new features/fu nctionalites in the Release. |
All the project leads authorise the issues are correctly labelled, mapped to the c orresponding project and milestone, etc., Features/Fun ctionalities changes (except for bugs fixes) identified post-freeze will be added to the Backlog. Exceptions to the above need TSC approval. |
|
|
Featu re/Functiona lity/Content Development |
The goal is to ensure that changes to features and fun ctionalities are captured and all content necessary for the In-Scope features & fun ctionalities will be developed as part of the release scope. |
Update Feature/F unctionality as we evolve. Develop / Update the contents for the release in-scope listed features & fun ctionalities |
||
|
Content Freeze |
M3 |
The goal of the Content Freeze is to mark the end of the features documented and provided the resolution for all impacting defects. After Content Freeze, there will be no new features/fun ctionalities are allowed into the current release. Only the critical fixes are allowed. |
All the project leads review the document and ensure all the planned features are documented and fixes are available before end of the Content Freeze. Uncompleted features/f unctionality will be added to the Backlog. After discussed and approved by the TSC. |
|
|
Content Review |
The goal is to carefully review and validate the contents and check for errors in the document. |
Validate content is within Release Scope and is technically correct. Check document for grammatical errors, extraneous items, etc. Close all In-Scope & reviewed pro jects/issues and move all others to Backlog after discussed and approved by the TSC. |
||
|
Content Review Freeze |
M4 |
The goal is to perform the final proof reading of the document before it is released. This is the release content completion milestone. |
All Projects are closed or else are marked Backlog. Discuss with TSC for any exceptional approval. |
|
|
Release Packaging |
The goal is to package the precise and reviewed document versions into a new release branch. |
Create new Release Branch after content review ends. |
||
|
Release Candidate |
RC0 |
The goal of the Release Candidate is to ensure the do cumentations are properly aligned, fully reviewed in the new release branch. |
Prioritise the required fixes and address them. If there are any critical fixes required then the fixes will be provided and it will be tagged with minor release. (Eg. Baldy 4.0.1) |
|
|
Release End |
The goal of the Release Sign-Off review is to ensure all the projects are successfully passed all the review. All the committed deliverables are available and passed the quality criteria. |
Table 1: Detailed Milestones
Dependencies between various Workstreams ¶
The various workstreams in CNTT are
-
Reference Model (RM)
-
Reference Architecture (RA)
-
Reference Implementation (RI)
-
Reference Conformance (RC)
The workstream dependency relationship in simple terms, Reference Conformance verifies and tests the Reference Implementation which follows the requirements and architecture defined in the CNTT Reference Architecture and Reference Architecture describes the high level system components and its interactions by adhering to the requirements and expectations set by the CNTT Reference Model which sets the standards for infrastructure abstraction, compliance and verification.
For the standard release stabilisation, On each release, All documents that are related to each other will have the same main version number as shown in the Figure 3.
There are two different tracks in CNTT
-
Virtualized workloads, deployed on OpenStack
-
Containerized workloads, deployed on Kubernetes
Each track follows the industry driven standards in the Reference Model as depicted in the below diagram.
Figure 3: CNTT WS Dependencies
Dependencies with Industry Communities ¶
The CNTT is collaboratively working with other standard bodies and open source communities such as:
-
OpenStack
-
OPNFV
-
ONAP
-
CNCF
-
ETSI NFV ISG
-
Telecom Infra Project (TIP)
Dependencies with OPNFV and OVP ¶
The OpenStack based work stream in CNTT community works closely with OPNFV by leveraging and evolving OPNFV continuous integration pipeline with automation installer and testing capabilities. The Reference Implementation (RI1) has dependencies with other industry communities like OPNFV as shown here and OVP as shown here . For information on the relationship to other communities, please read Reference Implementation Chapter 01 .
Figure 4: Relation to other communities.
Figure 5: CNTT Roadmap relation to OPNFV and OVP.
Dependencies with CNCF and OVP 2.0 ¶
TODO: Placeholder for RI2 dependency diagram
The Kubernetes based work stream in CNTT community works closely with CNCF by leveraging and evolving Kubernetes-based infrastructure and CNF continuous integration pipelines with automated installer and testing capabilities. The testing capabilities from the RC2 workstream will be used by OVP 2.0 for their badging program.