You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

This page provides a summary of project-by-project El-Alto release updates. The table shows the list of approved projects. In addition, it also lists a few subcommittees (use-case, architecture, security) and OVP.

ProjectKey UpdatesBenefits
A&AI
  • Upgraded OpenDaylight (ODL) version to Fluorine SR2
  • 14 bug fixes
  • 5 security fixes
  • Expanded support for VNF configuration
  • Greater stability, security
AAF


APPC

CLAMP
  • All major security issues resolved
  • Front-end GUI framework moving from Angular to the  React
  • Increased security
CCSDK
  • ODL Flourine SR2
  • Expanded support for VNF configuration
DCAE
  • DCAE Platform/Deployment updates
    • Dashboard deployed via Helm.
      • All DCAE Platform components: Cloudify, ConfigBindingService, InventoryAPI, ServiceChangeHandler, PolicyHandler, Healthcheck moved to Helm in Dublin
    • DCAE Cloudify deployed MS pods auto-cleanup (triggered via Helm)
  • DCAE MS Deployment options
    • Static deployment
      • Support integration usecases
    • Dynamic deployment
      • Cloudify/cli or Dashboard or CLAMP
  • Dynamic Topic/feed support
    • Dmaap Plugin enhancement (to support DMAAP-BusController interface)
    • Bootstrap updates
      • Configmap, consul entry, Update k8s plugin key to include configmap,
    • K8s plugin enhancement to support dynamic feed
    • Verified dynamic topic/feed on DMAAP Message Router and Data router interfacing components.
      • DataFileCollector and Pm-Mapper were pilot ms
    • Bp-gen tool enhanced to support dmaap plugin integrated blueprint generation
  • TLS Enablement
    • ConfigBindingService (deployment for El-Alto supports 2 parallel service – HTTP and HTTPS to mitigate client migration impact)
    • Deployment Handler
    • InventoryAPI
    • Cloudify
  • Security updates
    • Image optimization (alpine)
      • CBS, Inventory-API, ServiceChangeHandler, HV-VES, PRH, Son-handler
    • Non-root
      • SON-handler, PRH, ServiceChangeHandler, CBS, Inventory-API, HV_VES

DMaaPDMaaP Message Router:
  • New Features
    • Cert based authentication support in Message Router
    • Improved Kafka and Zookeeper cluster lookup
    • Pluggable Kafka server.properties,log4j.properties and Message Router logback.xml
  • Bug Fixes
    • Fixed for security vulnerabilities in Message Router
    • Fixed authorization issues in Message Router

DMaaP Data Router:

  • New Features
    • Enhanced logging to match Platform Maturity Logging Spec.
  • Bug Fixes
    • Fixed for security vulnerabilities in Message Router

DocumentationDocumentation improvements
External API Framework

Holmes

Integration

Logging
  • Reduce the number of vulnerability issues.  There are 15 issues addressed for this release.

MSB

Modeling
  • We have created a new repo , /modeling/etsi catalog, the major commit belongs to here
  • Regular model specification publication, /modeling/modelspec.

MultiCloud
  • Rebased most MultiCloud services to python3
  • Rebased MultiCloud services to latest Django packages to fix security vulnerability issues
  • 7 critical bugs fixed
  • Improved usability of MultiCloud k8s plugin

Music
  • MUSIC Control Panel UI based on ONAP Portal SDK
  • Eliminating ZK and building mechanism with Cassandra Light Weight Transaction for locking to simplify containerization and boost performance
  • AAF CADI Support
  • Keyspace Based logging
  • Internal retry mechanisms
  • MUSIC API improvements to allow multiple non-blocking reads to improve performance
  • MDBC 2.0 - Allows apps to gain resiliency and performance benefits of MUSIC without rewriting existing JDBC code, supports mixture of tables requiring immediate and eventual consistency. Built support for MySQL, MariaDB and Postgres database. Utilized existing open source Avatica project and filled the solution gaps with connection pool support and optimization.
  • Remediation of all 9 open Black Duck, 28 Fortify and 5 Sonar reported issues.

CLI1. ONAP CLI is used to end-end automation of VNF service provision and termination for both HEAT and TOSCA based VNF service.
2. Multi-level orchestration capability is made available to use and user could use python, or similar scripting/workflow engine for the same
3. VNF Test Platform(VTP) has used the Open Command Platform (OCOMP) – part of ONAP CLI project, for VNF life cycle testing (create and delete)
4. ONAP CLI for ONAP Dublin version is stabilized to use it for both service provisioning and testing purpose
5. ONAP CLI for el alto is enabled as experimental (dev) mode

OOM

OOF

UUI

Policy

Portal
  • Bug fixes and security enhancements
    • Specifically, addressed OJSI security enhancements and also fixed security issues reported by NexusIQ scan tool. As part of maintenance, enhanced known MariaDB/UX bugs and improved deployment helm charts.

SDN-C

SDC
  • Fixed 12 OJSI tickets
  • Integrated with AAF for certificates, so SDC works in HTTPS-only mode;
  • 8% more test coverage
  • Migrated to OParent
  • Upgraded DB infrastructure (Titan to JanusGraph)
  • And fixed 60 defects

SO

VF-C

1. VF-C add 15 csit test cases to cover more API and code branch

2. Optimize NSLCM, catalog, VNFLCM code and 20% code reduction

3. Leverage existing VF-C capabilities to Support OVP TOSCA VNF validation.

4. Integrate with CLI and improve the VF-C usability


VID

VVP/VNFSDK/VNF Requirements

VNFSDK:

  • TOSCA based VNF validation enabled for support OVP & CVC.
  • TOSCA based VNF compliance check based on some operator requirements.
  • SDC now integrated VNFSDK VTP on VNF validation.
  • ETSI SOL004 Security check (CMS signature validation) enabled.
  • Code quality improvement.(e.g. replace the Jackson to Gson, sonar issue fix)
  • A C++ implement of VES spec 7.0.1 on ves-agent.

VNF Requirements:

  • Defined reference test cases for VNF onboarding and instantiation to further expand the compliance badge scope available in the OPNFV Verified Program (OVP).
    • Covers both Heat-based and TOSCA-based VNFs
  • Over 30 requirement changes across VNF packaging, security, monitoring, and management to ensure VNF Providers can more readily integrate with ONAP in a compliant and secure manner

VVP:

  • New features:
    • VNF Preload Generation
      • Executing the VVP validation scripts will now generate valid preloads for each VF module present in a VNF
      • This simplifies the creation of preloads, and greatly reduces the chance of errors during instantiation due to an incomplete or malformed preload
      • Supports both VNF API and GR API formats
  • Security, Performance, and Bug Fixes:
    • Improved performance of validating complex VNFs by > 30%
    • Improved security by adding bandit library to perform code scans on each commit
    • Aligned VVP validation scripts with the latest version of the VNF Heat Template Requirements
    • Improved error messages, enhanced report readability for users
    • Refactored code to reduce code complexity and increase code re-use

Benchmark

Completed

  • The performance test script of vfw has been developed 90%. Before we have run the basic functions on the B version, we have not tested the concurrent version in the B version. Last month and the integration group meeting, the integration team suggested that we switch to the D version of the vfw performance test.
  • The vcpe performance test script has been developed. On the onap dublin version, we create only one virtual machine model. And use the modified vcpe script to create a service instance and virtual machine. The concurrent creation of a single virtual machine script, the completion of 20 concurrent tests, and the recording of test results

Work in progress

  • Find the reason why the virtual machine was not successfully created in the 20 concurrent test in the vcpe performance test.
  • Transplant the beijing version of the benchmark test mock server, simulate openstack request processing, and then concurrently create a virtual machine test.

Use Case Subcommittee No new use cases
Arch SubcommitteeNo architectural change
Security Subcommittee

OVP
  • Expanded support OPNFV Verified Program (OVP) VNF badges to now cover onboarding and instantiation of a VNF
    • In Dublin, the initial launch validated that VNF packages were compliant with ONAP’s VNF Requirements
    • Now the tests will automatically onboard, model, distribute, and instantiate the service to further verify compatibility
    • This will serve as the basis for future validations against running VNFs
    • Supports Heat and TOSCA based VNFs
    • Additional Details
    • Involved projects: VVP, Integration, and VNFSDK

General

  • No labels