The ONAP El Alto release increases confidence in production environments by focusing on security, usability, and stability as well as advancing other non-functional elements as evidenced by 2500+ epics, user stories, tasks, and defects addressed.
The fifth ONAP release — code-named El Alto — changes little in the functionality, but instead improves the overall quality of ONAP to increase the confidence in production deployments. The three themes of this release were: security by design, document as you code, and increasing test coverage and end-to-end test automation. These three themes contributed to greater security, usability and stability, continuing the work the community has always focused on with respect to S3P: stability, scalability, security, and performance. Other focus areas were scalability, performance, resilience, code footprint reduction, continuous integration, and reduction of technical debt. The release also contains some incremental functional and OVP related enhancements. The shorter release cycle in El Alto (4 months instead of the usual 6) paves the way for shorter release cycles moving ONAP to a more agile workflow.
- 5th ONAP release
- Commits: 8,507
- Developers: 347
- Organizations: 26
- Active Projects: 30
- Epics, User Stories, Tasks, and Defects addressed: 2,500+
- Bugs Fixed: 800+
The El-Alto release was driven by three themes:
- "Security by Design" — Seeking to make components free of vulnerabilities and impervious to attack.
- "Document as You Code" — Improving documentation library, developing new user guides, and integrating Swagger.
- "Don't Break the Build" — Increasing test coverage and E2E Test automation.
Additionally, several enhancements were also made to existing features like CDS.
The El Alto release adopted a security-by-design approach with the goal of making components free of vulnerabilities and impervious to attack. As a result, El Alto has a large number of security fixes, though more work remains. Moreover, the security release notes are of much higher quality than previous releases informing the user what has been addressed.
For the overall El Alto release, the number of exposed HTTP ports has significantly reduced to just 21 while some exposed ports such as SDN-C portal have been disabled entirely. 12 CVEs (common vulnerabilities and exposures) have been fixed and 7 are still being worked on. 44 ONAP security issues have been resolved and 19 still in progress.
On a related topic, the Core Infrastructure Initiative (CII) offers CII Best Practices badges to reflect an open source secure development maturity model. Projects having a CII badge showcase the project’s commitment to security. For ONAP, majority of the projects pass the CII badge, with a handful at 80-90% passing level. The Silver and Gold level progress has improved since the Dublin release as follows:
3% (1 project)
< 40% Silver
3% (1 project)
7% (2 projects)
10% (3 projects)
< 20% Gold
Numerous projects have also addressed security. First, a number of security issues have been fixed. For example, 42 security issues in Music, 11 in SDN-C, 5 in APP-C, 4 in OOF, 1 in VID, and several across CLAMP, DMaaP, Portal, and other projects have been addressed. Next, several projects include more secure libraries. For example the Portal framework includes Springframework 4.3.24, VVP includes Bandit, Multicloud includes a more secure version of Django, Multicloud includes Istio, and Integration and SDC include oParent 2.1.0. Moreover, DCAE has enabled TLS (Transport Layer Security) for a number of platform components to secure control plane data flow. The MSB project can now register https services via its UI and the SDC project works in https-only mode via AAF certificate integration. In addition, AAF includes new auto-configuration, global location strategy for locator, and dynamic certificate generation capabilities. The use of AAF has gone up in projects such as DMaaP, with the support for certificate based authentication for Message Router in DMaaP, Music, and SDC.
Documentation & Usability:
Developers adopted a document-as-you-code approach in the El Alto release that included improving the documentation library, developing new user guides, and integrating Swagger. El Alto release also includes Postman collections in the user guide making it significantly easier to interact with the external API.
The release includes additional aspects that contribute to improved usability as well. The Music project now includes both an API and a UI for ease of use. The external API project comes with a number of Postman collections that make it much easier to exercise the correct APIs to accomplish a specific outcome. The Multicloud project has created a lightweight profile of ONAP for use cases where the only cloud supported is Kubernetes. This profile is named, as one might expect, ONAP4KS. The VF-C project enables user interaction through command line with integration with the CLI project. Next, the VVP project provides scripts that will automatically generate valid Day 0 configuration (preloads) for each VF module to simplify design tasks and to eliminate manual errors. VVP also includes other usability improvements such as more clear error messages and enhanced report readability.
Most projects also addressed a significant number of bugs. For example, SO fixed 156 bugs, SDC 60, CCSDK 45, SDN-C 41, OOM 25, Policy 22, and so on.
The overall stability of ONAP also improved as a result of end-to-end CI automation (see Continuous Integration section below).
Both the MSB and SDC projects had scalability improvements.
Performance: VVP has improved the performance of validating complex VNFs by more than 30%. The Music project addressed performance bottlenecks by switching to a Cassandra based lightweight transaction for locking, supporting multiple non-blocking reads, and using MDBC 2.0 to increase database performance without rewriting the database code. Distinct from ONAP performance, is VNFperformance. The Benchmark project has been developing performance testing scripts for the vFW and vCPE use case blueprints.
Recent progress on the Music project enables better resilience across clouds. In addition, the Music project itself is more resilient through its incorporation of the MDBC library.
ONAP continues to become easier to manage. For example, DMaaP, MUSIC, and other projects increased their support for logging.
Code footprint reduction:
The code footprint reduction effort started with the Dublin release and has continued through El Alto. Project such as CLAMP reduced the footprint by 40%, VF-C by 20% and DCAE by 30%. Project such as A&AI converted all microservices to Alpine OS further reducing their footprint.
The continuous integration (CI) framework of ONAP is important to demonstrate the community’s DevOps midframe and to improve the speed of innovation.
Technical debt reduction:
The El Alto release also reduced technical debt.
Examples of this activity range from moving the CLAMP GUI from Angular to React and refactoring CLAMP and VVP code. The SDN-C project separated out the CDS Helm chart for ease of installation and maintenance. The DCAE project now includes automatic cleanup of deployed microservices and image optimization. Next, DMaaP improved Kafka and Zookeeper cluster lookup. Finally, the Documentation team made some much needed process improvements.
Technical debt is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer.
Technical debt can be compared to monetary debt. If technical debt is not repaid, it can accumulate 'interest', making it harder to implement changes later on.
Despite being primarily a non-functional release, El Alto does include several incremental feature enhancements.
The design time framework has been enhanced with greater support for SOL004 TOSCA VNF packages where security check is now enabled. The modeling team created a new repository to provide package management and parser functionality as microservices, so that these functions are modular and can be reused. Further, the modeling team created new specifications for the Root, business and interaction, and VES 7.1 models. The Root model establishes a common base for ONAP informational model. The other models help with different runtime operations.
Orchestration and Lifecycle Management — enhancement include:
- CDS provides greater support for vLB and vFW use case blueprints and additional ease-of-use features.
- AAF uses global location strategy for locator and dynamic certificate generation for apps.
- APP-C and SDN-C have integrated newer versions of OpenDaylight (Fluorine SR2 for APP-C and Neon for SDN-C). SDN-C includes a configuration database and support for Netconf notifications that can be used to trigger closed loops.
Automation — enhancements include:
- DCAE supports dynamic topic/feed support in DMaaP.
- Policy supports dynamic policy translation and CDS as a controller triggered by a control closed-loop.
VNF Interop Compliance and Validation
As part of the OVP program, ONAP CLI is used for the upcoming VNF validation testing through an initiative called VNF Test Platform (VTP).
Also, the VNF Requirements project has 30 more requirements around VNF packaging, security, monitoring, and management to improve VNF interop and security compliance. VNF SDK and VVP have been enhanced with additional capabilities and tests to improve existing VNF compliance testing. For example, VVP now generates day 0 configuration preloads through scripts simplifying the overall process and eliminating errors.
The next ONAP release slated for 1H of 2019 is code named Frankfurt. The focus of Frankfurt will be more complete 5G support. The release after Frankfurt is codenamed Guilin.
Next LFN Developer and Testing Forum, Prague, January 13-16, 2020.