DCAE R8 M2 Release Planning
Overview
Project Name | Enter the name of the project |
|---|---|
Target Release Name | Honolulu |
Project Lifecycle State | Mature. Refer to ONAP Charter, section 3.3 Project Lifecycle for further information |
Participating Company | AT&T, Nokia, Ericsson, Wipro, ChinaMobile, T-Mobile |
Scope
What is this release trying to address?
Release Focus
DCAE Focus for R8 is on following
ONAP R8 Usecase & Feature requirement
TSC/SECCOM Global requirements
DCAE Transformation to support Helm deployment for services
General platform optimization (Cloudify upgrade for python 3.6)
Reducing DCAE backlogs + security fixes
Honolulu Usecases with DCAE impact
REQ# | DCAE Commit Status | DCAE Impact Assessment | DCAE JIRA # |
REQ-440 - E2E Network Slicing use case requirements for Honolulu release | YES |
Commitment from WIPRO, China Mobile | |
REQ-429 - Use Case for ONAP-based SON for 5G networks | YES | SON-Handler Enhancements (CPS integration and VES alignment) Commitment from WIPRO |
Honolulu Features with DCAE Impact
REQ# | DCAE Commit Status | DCAE Impact Assessment | DCAE JIRA # |
REQ-433 - ONAP/3GPP & O-RAN Alignment-Standards Defined Notifications over VES (Honolulu) | YES | Standard-defined openAPI onboarding (K8S configMap update for VEScollector) Commitment from Nokia | TBC |
REQ-431 - CMPv2 enhancements in R8 | YES | DFC & RestConf(stretch) integration + OOM/cert-manager integration Commitment from Nokia |
Honolulu Spec with DCAE Impact
REQ# | DCAE Commit Status | DCAE Impact Assessment | DCAE JIRA # |
REQ-422 - Bulk PM / PM Data Control Improvements | YES | PMSH enhancement for dynamic filter/subscription change Commitment from Ericsson | |
NA (Backlog) | YES | MOD updates Commitment from AT&T | |
NA (Backlog) | YES | Generic mechanism to attach K8S ConfigMaps to DCAE apps. through spec/bp-gen/plugin (VES and DFC) Commitment from Nokia | |
NA (Backlog) | YES | BP-gen Enhancements
Commitment from Nokia | |
NA (Backlog) | Stretch | VESCollector Enhancements – Event publish order issue Commitment from Nokia | |
NA (Backlog) | Stretch | Plugin path/load optimization: Taking release from PATH on raw/plugin repo location (rely on version) and update bootstrap/cloudify build | |
NA (Backlog) | Stretch | Eliminate use of Consul service discovery in DCAE |
Honolulu POC (DCAE impact)
REQ# | DCAE Commit Status | DCAE Impact Assessment | DCAE JIRA # |
REQ-479 - DCAE Transformation to support Helm | YES |
Commitment from AT&T, Independent Contributors | |
REQ-478 - PoC - TOSCA Defined Control Loop on Honolulu Release | NO | Need more info | |
REQ-470 - DCAE extension for collecting files from HTTP servers | YES | DFC Enhancement Commitment from Nokia |
Best Practice Candidates
REQ# | DCAE Commit Status | DCAE Impact Assesment | DCAE JIRA # |
REQ-443 - CONTINUATION OF CII BADGING SCORE IMPROVEMENTS FOR SILVER LEVEL | Stretch | ||
REQ-441 - LOGS MANAGEMENT - PHASE 1: COMMON PLACE FOR DATA | NO | Need more info | |
REQ-439 - CONTINUATION OF PACKAGES UPGRADES IN DIRECT DEPENDENCIES | YES | Tcagen2, DFC, RESTConf, VES, InventoryAPI, MOD-runtimeAPI, Mapper, PM-Mapper, PRH, SON-Handler | |
REQ-432 - IPv4/IPv6 dual stack support in ONAP (Honolulu) | YES | CFY Plugin to support IPv6 service exposure + VES Spec updates Commitment from Nokia | |
Global Requirements
REQ# | DCAE Commit Status | DCAE Impact Assesment | DCAE JIRA # |
REQ-438 - COMPLETION OF JAVA LANGUAGE UPDATE (v8 → v11) | YES | Require exception for MOD/genprocessor/designtool/nifi-registry Risk #6 (Honolulu Risks) | |
REQ-437 - COMPLETION OF PYTHON LANGUAGE UPDATE (v2.7 → v3.8 | YES |
Commitment from T-mobile, Independent contributon Risk #7 (Honolulu Risks) |
Note: The above commitment is consistent with Honolulu Impact View per Component (as of 1/19/2021)
New Services introduced for this release
Following new services will be delivered in R8
KPI Computation MS (REQ-440 )
Repository : https://git.onap.org/dcaegen2/services/tree/components/kpi-computation-ms (introduced as new subproject under existing repo)
VES-OpenAPI-Manager (REQ-433)
Repository : https://gerrit.onap.org/r/admin/repos/dcaegen2/platform/ves-openapi-manager (New repo)
DCAE-service-policy-Sync (REQ-479)
Repository : https://git.onap.org/dcaegen2/deployments/tree/dcae-services-policy-sync (introduced a new subproject/module under existing repo)
Platform Maturity
Platform Maturity (i.e., S3P items) Honolulu Release Platform Maturity
Green color → Target level ( details see Platform Maturity below)
Performance: Level 1
Stability: Level 2
Resiliency: Level 2
Security: Level 1+
Scalability: Level 1
Manageability: Level 1+
Usability: Level 1+
Minimum Viable Product
The MVP of DCAE will include the necessary subcomponents supporting the primary objectives: meeting platform maturity goals and supporting the use cases.
DCAE Service specific components
DCAE-MOD deployment is optional and will include following component (controlled via helm chart configuration under OOM)
Genprocessor
MOD/NiFI UI
Distributorapi
Runtimeapi
Onboardingapi
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.
Epics
Stories
Longer term roadmap
DCAE is the collection and analytics platform serving ONAP. Improving upon the DCAE MS catalog to add new services for data collection, analytics and the number of open/close control loops.
DCAE-MOD evolution and integration with CLAMP and Policy
Release Deliverables
Indicate the outcome (Executable, Source Code, Library, API description, Tool, Documentation, Release Note...) of this release.
Deliverable Name | Deliverable Description |
|---|---|
Component spec | All ms added into DCAE should provide meta data representation of the component itself; will be used to generate design flow under MOD and enable blueprint generation |
blueprints | Executable/SourceCode |
plugins | SourceCode and wagon files under nexus/raw |
deployment-handler | SourceCode/Docker image |
servicechange-handler | SourceCode/Docker image |
inventory-api | SourceCode/Docker image |
policy-handler | SourceCode/Docker image |
configbinding | SourceCode/Docker image |
ves | SourceCode/Docker image |
hv-ves-collector | SourceCode/jar/Docker image |
prh | SourceCode/jar/Docker image |
dcae-mod | SourceCode/jar/Docker image/Documentation |
tca-gen2 | SourceCode/jar/Docker image |
Note: Only default platform components and bootstrapped MS is listed on table above. DCAE also include dynamic service components deployed based on usecases. For a complete set of available DCAE MS - refer https://docs.onap.org/projects/onap-dcaegen2/en/latest/sections/release-notes.html#deliverables
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 Resources and Repositories (Deprecated) in the centralized page.
In addition to existing platform/service component, following new components are targeted for Honolulu.
Deliverable | Repository | Components Description |
KPI Computation MS | https://git.onap.org/dcaegen2/services/tree/components/kpi-computation-ms (introduced as new subproject under existing repo) | |
VES-OpenAPI-Manager | https://gerrit.onap.org/r/admin/repos/dcaegen2/platform/ves-openapi-manager (New repo) | |
DCAE-service-policy-Sync | https://git.onap.org/dcaegen2/deployments/tree/dcae-services-policy-sync (introduced a new subproject/module under existing repo) |
ONAP Dependencies
List the other ONAP projects you depend on.
DCAE depends on the the following components as part of the general ONAP architecture:
AAI: DCAE MS retrieves and updates VNF data from/to AAI
DMaaP: Message bus for communication with other components in the solution
Policy - For managing application configuration policy
CLAMP - For CL flow related MS instantiation and configuration
OOF - For SON handler support
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 Amsterdam architecture diagram_1.0.0.pptx.
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.
Target Architecture (REQ-479)
Platform Maturity
Refering to 2017-06-28 CII badging for ONAP.pptx and Platform Maturity Requirements (aka Carrier Grade), 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 |
|---|