Versions Compared

Old Version 13

changes.mady.by.user Vijay Kumar

Saved on

compared with

New Version 14

changes.mady.by.user Vijay Kumar

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: dcae updates

...

  • VESCollector 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 library)
  • 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)
  • 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)  https://wiki.onap.org/display/DW/Dublin+Release+Platform+ Frankfurt 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 2                    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.

...

Refering to CII Badging Security Program and Platform Maturity Requirements, 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.

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

Level 2

Level 2  - Dependent on integration team support

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 complaint)



    • 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
2 (STRETCH GOAL- based on resource availability)

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


  • API Incoming Dependencies

...