`<< Back `__ Roadmap ======= Table of Contents ----------------- - `Overview <#6.1>`__ - `Roadmap <#6.2.2>`__ - `High Level Roadmap <#6.2.1>`__ - `Detailed Roadmap <#6.2.2>`__ - `Detailed Milestones <#6.2.3>`__ - `Dependencies between various Workstreams <#6.3>`__ - `Dependencies with Industry Communities <#6.4>`__ - `Dependencies with OPNFV and OVP <#6.4.1>`__ - `Dependencies with CNCF and OVP 2.0 <#6.4.1>`__ Overview -------- - The activities of the CNTT community are articulated around `Projects <#project>`__, `Milestones <#2.3>`__ and `Releases <#release>`__. - 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 <./release_notes/release_process.md>`__. .. raw:: html

scope

Figure 1: Milestones

**Definitions** A project is: - Long term endeavour setup to deliver features across multiple releases as shown `here <./release_notes/>`__ - 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 <./release_notes/baldy.md>`__. - 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-1: Roadmap ------- High Level Roadmap ~~~~~~~~~~~~~~~~~~ .. raw:: html

scope

Figure 2: CNTT Technical Specification Roadmap

Detailed Roadmap ~~~~~~~~~~~~~~~~ Please refer to individual `release plans <./release_notes/>`__ and features for detailed roadmap. Detailed Milestones ~~~~~~~~~~~~~~~~~~~ +--------------+-----------+--------------+--------------+----------+ | Review | Milestone | Description | Activities | Comments | +==============+===========+==============+==============+==========+ | Kick-Off | M0 | The goal of | Name the | | | | | the release | Release and | | | | | Kick-Off is | create | | | | | to open the | appropriate | | | | | innovation | labels in | | | | | platform for | GitHub. | | | | | the intent | | | | | | to | | | | | | participate | | | | | | in the CNTT | | | | | | release. | | | | | | Release | | | | | | Kick-Off | | | | | | review takes | | | | | | place for | | | | | | each | | | | | | releases. | | | +--------------+-----------+--------------+--------------+----------+ | Planning & | | The goal of | Identity a | | | Scoping | | the Release | list of | | | | | Planning & | features and | | | | | Scoping is | f | | | | | to capture | unctionality | | | | | the initial | including | | | | | set of | from the | | | | | features and | backlog will | | | | | f | be developed | | | | | unctionality | and | | | | | that should | documented | | | | | be part of | as part of | | | | | the release | the current | | | | | along with | release. | | | | | pri | N.B. | | | | | oritisation. | 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 | M1 | The goal of | After the | | | Review | | the Release | review | | | | | Planning | cut-off date | | | | | review is to | any major | | | | | ensure the | features & | | | | | plan is | fun | | | | | complete, | ctionalities | | | | | sufficient, | changes will | | | | | and aligned | be added to | | | | | with release | the backlog | | | | | milestones. | unless it is | | | | | All people | approved by | | | | | resources | the TSC to | | | | | are | be added | | | | | identified, | into the | | | | | documented | current | | | | | and | scope of | | | | | committed. | 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 | | Feature/F | | | | Cha | | unctionality | Feature/F | | | nges/Logging | | changes to | unctionality | | | | | be part of | changes (in | | | | | current | Github) for | | | | | Release | 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 | All the | | | | | the Scope | project | | | | | Freeze is to | leads | | | | | mark the end | authorise | | | | | of adding | the issues | | | | | new | are | | | | | features/fu | correctly | | | | | nctionalites | labelled, | | | | | in the | mapped to | | | | | Release. | 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 | | The goal is | Update | | | re/Functiona | | to ensure | Feature/F | | | lity/Content | | that changes | unctionality | | | Development | | to features | as we | | | | | and | evolve. | | | | | fun | Develop / | | | | | ctionalities | Update the | | | | | are captured | contents for | | | | | and all | the release | | | | | content | in-scope | | | | | necessary | listed | | | | | for the | features & | | | | | In-Scope | fun | | | | | features & | ctionalities | | | | | fun | | | | | | ctionalities | | | | | | will be | | | | | | developed as | | | | | | part of the | | | | | | release | | | | | | scope. | | | +--------------+-----------+--------------+--------------+----------+ | Content | M3 | The goal of | All the | | | Freeze | | the Content | project | | | | | Freeze is to | leads review | | | | | mark the end | the document | | | | | of the | and ensure | | | | | features | all the | | | | | documented | planned | | | | | and provided | features are | | | | | the | documented | | | | | resolution | and fixes | | | | | for all | are | | | | | impacting | available | | | | | defects. | before end | | | | | After | of the | | | | | Content | Content | | | | | Freeze, | Freeze. | | | | | there will | Uncompleted | | | | | be no new | features/f | | | | | features/fun | unctionality | | | | | ctionalities | will be | | | | | are allowed | added to the | | | | | into the | Backlog. | | | | | current | After | | | | | release. | discussed | | | | | Only the | and approved | | | | | critical | by the TSC. | | | | | fixes are | | | | | | allowed. | | | +--------------+-----------+--------------+--------------+----------+ | Content | | The goal is | Validate | | | Review | | to carefully | content is | | | | | review and | within | | | | | validate the | Release | | | | | contents and | Scope and is | | | | | check for | technically | | | | | errors in | correct. | | | | | the | Check | | | | | document. | 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 | M4 | The goal is | All Projects | | | Review | | to perform | are closed | | | Freeze | | the final | or else are | | | | | proof | marked | | | | | reading of | Backlog. | | | | | the document | Discuss with | | | | | before it is | TSC for any | | | | | released. | exceptional | | | | | This is the | approval. | | | | | release | | | | | | content | | | | | | completion | | | | | | milestone. | | | +--------------+-----------+--------------+--------------+----------+ | Release | | The goal is | Create new | | | Packaging | | to package | Release | | | | | the precise | Branch after | | | | | and reviewed | content | | | | | document | review ends. | | | | | versions | | | | | | into a new | | | | | | release | | | | | | branch. | | | +--------------+-----------+--------------+--------------+----------+ | Release | RC0 | The goal of | Prioritise | | | Candidate | | the Release | the required | | | | | Candidate is | fixes and | | | | | to ensure | address | | | | | the | them. If | | | | | do | there are | | | | | cumentations | any critical | | | | | are properly | fixes | | | | | aligned, | required | | | | | fully | then the | | | | | reviewed in | fixes will | | | | | the new | be provided | | | | | release | and it will | | | | | branch. | 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. | | | +--------------+-----------+--------------+--------------+----------+ .. raw:: html

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 <../ref_cert>`__ verifies and tests the `Reference Implementation <../ref_impl>`__ which follows the requirements and architecture defined in the CNTT `Reference Architecture <../ref_arch>`__ 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 <../ref_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. .. raw:: html

CNTT WS Dependencies

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 <../ref_impl/cntt-ri/chapters/chapter01.md#1.3>`__ and OVP as shown `here <../ref_impl/cntt-ri/chapters/chapter01.md#1.3>`__. For information on the relationship to other communities, please read `Reference Implementation Chapter 01 <../ref_impl/cntt-ri/chapters/chapter01.md#1.3>`__. .. raw:: html

Relation to other communities

Figure 4: Relation to other communities.

.. raw:: html

Relation to other communities

Figure 5: CNTT Roadmap relation to OPNFV and OVP.

.. _dependencies-with-cncf-and-ovp-20: 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.