Versions Compared

Key

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

Recognizing the contributions of your peers to the success in delivering ONAP Honolulu

...

Nominations open through 17:00 pacific on
TSC Voting Closes 17:00 pacific on  

...

Nominated CandidateReason for Nomination
DCAE ProjectDCAE project had major rearchitecture initiative started in Honolulu release to migrate DCAE microservices deployments from Cloudify to Helm. This was driven based on community requests to align all ONAP component deployment through helm and under OOM.  In H release, we delivered migration of subset of DCAE services (ves/prh/tcagen2/hv-ves) to helm, maintaining complete backward compatibility with Cloudify based deployment and S3P goals. 
The work done in H release provided a base for Istanbul to add new features through common svc template (under OOM) and migration of rest of DCAE components to helm. As the solution was completly backward compatible - operator/user have choice to instantiate DCAE either via helm or cloudify or both. Inaddition to transformation initative,  several components including Cloudify-Manager, Bootstrap, Plugins, PolicyHandler were upgraded to Python3 in Honolulu part of S3P (security) improvements.
Integration project

The first automated stability tests have been included in Weekly CI in honolulu. It consists in 2 long duration tests, 1 dealing with onboarding (stressing mainly the SDC) and 1 with an instantiation (involving SO, SDNC, AAI and SDC). Unlike the previous stability tests, which were running only 1 test continuously it was possible to initiate reasonable load on the system (5 // onboarding during 24h and 10 // instantiation during 24) and to detect issues  on cassandra and mariadb-galera. Some optimization have been suggested, work is still in progress but thanks to these tests it is possible to get a first real feedback on the system under load. These tests were possible thanks to an light overlay development on top of the smoke tests developed by the integration team based on onapsdk. kudos to Natacha Chéreau an intern who help the integration project to finalize this framework and integrated the tool in CI. See stability chapter in https://docs.onap.org/projects/onap-integration/en/latest/integration-s3p.html#integration-s3p)

Service Orchestrator Project

SO underwent major transformation in the H release making it closer to being a true production grade project in ONAP, some of the key improvements were:

  • SO project improved its code structure making it easier to resolve the issues
  • Implemented true plug and play for new adapters to be added seamlessly
  • Underwent a major changes to its internal architecture to perform better orchestration
  • Improved its self-verification process by bringing in new CSIT cases & gating process to its verify builds
  • Brought in on need basis deployment of its components for specific function needs thus reducing the footprint

SO is of the most important projects of ONAP with a huge changes accounted for every release. It is growing by leaps and bounds as new functional features are added release on release. This brought a huge technical debt that started accumulating. Resolving them was a mammoth task that demanded a huge amount of effort from all the stake holders in H release. Prior to this SO has been a single repo on Gerrit as, this was a huge code block with a huge impact on debugging, build, time to market and overall maintenance. Any changes in SO required the entire code to be built leading to an huge effort and delays in delivery.

We addressed most of these issues based on the lessons learnt from the previous releases and are relentlessly working on bringing about further improvements in the upcoming releases.







...