Versions Compared

Key

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

...

Frankfurt Features with DCAE Impact

 Image Removed

Note: Features highlighted in RED need further discussion with owners; not committed yet

Frankfurt Usecases with DCAE Impact

Image Removed

Non-Functional Requirement 


  • Self-Serve Control Loops
  • Policy Update Notifications
  • 5G / OOF SON Enhancement
  • 5G / Run-time Data Persistency
  • Modeling: 5G / ORAN & 3GPP Standards Harmonization
  • 5G / Bulk PM / PM Control
  • 5G / Bulk PM / Secure Communication between xNFs and ONAP
  • 5G / PM dictionary
  • PNF / Plug and Play

 

Non-Functional Requirement 

  • VESCollector EnhancementsVESCollector Enhancements
    • DCAEGEN2-1594 – VESCollector healthcheck support when authentication is enabled; Validation blocked by DCAEGEN2-1757 – spring version issue
    • DCAEGEN2-1483  – Event publish order issue
    • DCAEGEN2-1484  - Set dynamic partitionkey (stretch goal)
    • DCAEGEN2-1774 - Optimize VES schema load by retain in-memory than loading file each time (dint find corresponding jira, created new today)
    • DCAEGEN2-608   - Performance/benchmarking
    • DCAEGEN2-1776  - Remove certOnly and basicAuth from authentication methods
    • DCAEGEN2-1779  - Switch VES collector's K8s health checks to HTTPS
  • TCA-gen2 delivery and replace TCA/cdap (DCAEGEN2-1907)
    • Mongodb support for tca-gen2
  • Deployment optimization (Plugin load, reduce bootstrap, Cloudify upgrade)
  • Python 3.x Plugin upgrade (5.0.5 - Cloudify mock available; 5.1 – full python 3.x)
  • Python 3.x support (Policy libraryDCAEGEN2-1519)
    • DCAEGEN2-1548 - Python 3.x upgrade for Policy Lib
  • DCAE Dashboard Fixes and security updates
  • Automated test improvement (csit/robot)
  • DCAE Helm chart org (OOM-1574)
  • Multi-site registry alignment (DCAEGEN2-1879) - (stretch goal)
  • DCAE TLS init container improvement 
  • OTI Phase1 (contribute new platform component) (DCAEGEN2-1908)
    • OTI Integration impacts following components (k8splugin, stateful set support, OTI-handler, OTI-EventProc, CBS*, kube2pyconsul, PG*, Nginxproxy, bp-gen). For Frankfurt, OTI-Handler and OTI-Event proc component seed code will be delivered and integrated with ONAP CI process. The full platform integration will be deferred to Guilin release.
  • DL Handlers integration DCAEGEN2-1849
  • MOD Integration DCAEGEN2-1852
  • Sonar coverage improvement (60% target for Frankfurt) (stretch goal)
  • Outstanding OJSI Jira (OJSI Tickets Status)
  • Java 11 Upgrade (DCAEGEN2-1918) (stretch goal)
  • Following additional TSC MUST have requirement will be handled in this release.
    • Document current upgrade component strategy
    • SECCOM Perform Software Composition Analysis - Vulnerability tables
    • SECCOM Password removal from OOM HELM charts
      • No DCAE impacts identified; will handle new charts contribution for MOD to align with Security needs.
    • SECCOM HTTPS communication vs. HTTP

      config-binding-service30415
      dashboard30418


Platform Maturity

 Platform Maturity (i.e., S3P items)  Frankfurt Release Platform Maturity

...

Sub-components are repositories and are consolidated in a single centralized place. Edit the Resouce and Repositories in the centralized page.

...

DeliverableRepository Maven Group ID

Components Description

pmsh

dcaegen2/services

org.onap.dcaegen2.services.pmsh

PM Subscription Handler

tca-gen2dcaegen2/analytics/tca-gen2  

org.onap.dcaegen2.analytics.tca-gen2

Standalone TCA
heartbeatdcaegen2/services/heartbeat org.onap.dcaegen2.services.heartbeat Missing Heartbeat Micro Services

ONAP Dependencies





ONAP Dependencies

List List the other ONAP projects you depend on.

...

AreaActual LevelTargeted Level for current ReleaseHow, EvidencesComments
Performance11
    • Level 0: no performance testing done
    • Level 1: baseline performance criteria identified and measured  (such as response time, transaction/message rate, latency, footprint, etc. to be defined on per component)
    • Level 2: performance improvement plan created 
    • Level 3: performance improvement plan implemented for 1 release (improvement measured for equivalent functionality & equivalent hardware)
Stability2

2




    • Level 0: none beyond release requirements
    • Level 1: 72 hour component-level soak test (random test transactions with 80% code coverage; steady load)
    • Level 2: 72 hour platform-level soak test (random test transactions with 80% code coverage; steady load)
    • Level 3: track record over 6 months of reduced defect rate
Resiliency22
    • 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+  (Most DCAE components are complaint; will address remaining in Frankfurt based on resource availability)



    • Level 0: None
    • Level 1: CII Passing badge
      • Including no critical and high known vulnerabilities > 60 days old
    • Level 2: CII Silver badge, plus:
      • All internal/external system communications shall be able to be encrypted.
      • All internal/external service calls shall have common role-based access control and authorization using CADI framework.
    • Level 3: CII Gold badge 
Scalability1

1



    • Level 0: no ability to scale
    • Level 1: supports single site horizontal scale out and scale in, independent of other components
    • Level 2: supports geographic scaling, independent of other components
    • Level 3: support scaling (interoperability) across multiple ONAP instances
Manageability1

1+  (except Logging where some DCAE components are not complaintExcept logging, all other requirements are met)



    • Level 1:
    • All ONAP components will use a single logging system.
    • Instantiation of a simple ONAP system should be accomplished in <1 hour with a minimal footprint
    • Level 2:
      • A component can be independently upgraded without impacting operation interacting components
      • Component configuration to be externalized in a common fashion across ONAP projects
      • All application logging to adhere to ONAP Application Logging Specification v1.2
      • Implement guidelines for a minimal container footprint
    • Level 3
      • Transaction tracing across components
Usability1

1+



    • Level 1:
      • User guide created
      • Deployment documentation
      • API documentation
      • Adherence to coding guidelines
    • Level 2:
    • Level 3
      • Consistent UI across ONAP projects
      • Usability testing conducted
      • API Documentation
    • Level 4

...

Risk identifiedMitigation PlanContingency Plan

Cloudify support for Python 3.x not available during Frankfurt timeframe. This impacts migration of Cloudify and associated plugins in Frankfurt (DCAEGEN2-1546)

Continue El-Alto version of Cloudify and Plugins under python 2.7None
  • Resources

Fill out the Resources Committed to the Release centralized page


  • Release Milestone

...

This section is optional and may be used to document internal milestones within a project team or multiple project teams. For instance, in the case the team has made agreement with other team to deliver some artifacts on a certain date that are not in the release milestone, it is erecommended to provide these agreements and dates in this section.

It is not expected to have a detailed project plan.

in this section.

It is not expected to have a detailed project plan.

DateSprint#No of days Deliverable

  -  

DCAE Frankfurt Sprint 114
  • Seed code for new components
  • jjb definition for verify/merge/sonar/clm

  -  

DCAE Frankfurt Sprint 215 
  • Atleast 75% of Functional delivery
  • Atleast 30% of release/compliance (coverage & security)
  • Successful container build (new components)
  • SDK version for Frankfurt to be baselined and released

  -  

DCAE Frankfurt Sprint 315
  • 95% of Functional delivery
  • Atleast 70% of release/compliance (coverage & security)
  • API definition formalized
  • Integration test plan completed
  • CSIT/automated test delivery

M2/M3 checkpoint - 1/21

  -  

DCAE Frankfurt Sprint 4 15


  • API definition formalized and shared with impacted teams
  • 100% Functionality
  • Atleast 90% of release/complaince (coverage & security)
  • CSIT/automated test completed for new components
  • Documentation repo updates (API updates & new MS/component) - Frankfurt Documentation
  • Deployment artifacts (helm for platform component; spec file and/or blueprint for service component)  & onap integration

 -  

DCAE Frankfurt Sprint 515 

M4   

  • 100% of release/compliance (coverage & security)
  • Validate deployment/integration with ONAP/DCAE deploy
  • Documentation update for deployment/configuration/architecture/logging
  • Update wiki for new components deployment for usecase owners
  • Demo for new components introduced
  • Pair-wise testing

  -  

DCAE Frankfurt Sprint 6 (RC prep) 15

RC0

  • Fix Integration blockers
  • Automated robot test, CSIT & daily build jobs must pass
  • Release java artifacts
  • Release docker containers
  • Update OOM chart/blueprint/documentation to reflect correct version
  • Branching
DateProjectDeliverableTo fill outTo fill outTo fill out
  • 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

...