Jack is working hard on DCAE for a lot of years. His work in OOM made him a committer also on this project. Being retired, Jack is working only for the good of ONAP and it's dedication is really a plus for the whole ONAP project

Jack contribution has been instrumental in moving DCAE to new architecture under OOM/helm for Istanbul release. Jack has been supporting ONAP as committer/contributor for several ONAP project - DCAE, CCSDK since inception, recently approved as OOM committer based his continued good track record.  Jack is serving ONAP post retirement (from AT&T since mid-2020) as an independent contributor - his efforts and dedication for ONAP is extremely commendable.

Lukasz was strongly involved in CNF journey: very active in the CNCF Task force, contributions to Service Orchestrator. He brings a lot of support to the community, mentorship by providing tutorials, education people, DDF presentations. He was very active to provide support for the 5G Super Blueprint especially to solve integration isseus issue with Magma.

It is also important to state that this work is reused for the 5G SA experimental project PIkeo launched in France.

As part of the Istanbul release, Lukasz drove the CNF the CNF Orchestration Enhancements (REQ-627)

CNF Orchestration Enhancements (REQ-627)

• Synchronization of k8s resource objects between k8scluster and AAI as a part of CNF instantiation process
• Dedicated CNF Healthcheck Workflow in SO
• Control of the order of the CNF and helm package deployment in SO macro request
• Various k8s resource management improvements in k8splugin
  • Helm 3.5 package spec support
  • Support for Helm pre/post- create and delete Hooks 
  • Improved Config API
  • Status API returns the real status of deployed helm package
  • Better aligned with Helm processing spec
  • Important bug fixes

- With these changes introduced, information about created CNF resources in k8s cluster are now available. This information can be utilized later on i.e. in closed-loop context. CNF Healthcheck Workflow in SO will let to monitor the status of CNF deployed into k8s cluster and whether it is healthy or not. Further changes in k8splugin related to Helm spec support allow for the better and more reliable deployment of complex CNFs defined as a helm package. In addition, "ONAP for Enterprise" Task Force and "5G Super Blueprint" LFN initiative continously benefit from any CNF requirement led by Lukasz.

The DCAE project continue to evolve their platform maturity requirements release after release. They reached up to 96% Silver Level - CII Badging as part of their Istanbul release - Istanbul Release Platform MaturityIn addition, the DCAE project made 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 Istanbul release, all

Key Security updates for Istanbul

• Removed GPLv3 license from software by switching to onap/integration base images for CBS, Policy-Handler, VES-Mapper, PM-mapper, TCAgen2, DL Feeder, DL-DES (DCAEGEN2-2455)
• Healthcheck container Py3 upgrade  (DCAEGEN2-2737)
• Vulnerability updates for several DCAE MS (TCA-gen2, DataFileCollector,RESTConf, VES,Mapper, PM-Mapper, PRH, SON-handler, KPI-MS, Slice-Analysis MS) (DCAEGEN2-2768)
• DL feeder/DES switched to PG (from mariaDB) and made complaint with non-root pod. 

Architecture Alignment - Major progress made toward DCAE architecture tranformation to remove Cloudify/Consul dependencies; this simplies the architecture and deployment of DCAE MS. All DCAE microservices migration to helm was completed in Istanbul release. Since Honolulu, 13 additional mS MS has been delivered added for Helm deployment support and (with parallel support under Cloudify/blueprint (legacy) retained for regression/backward compatibility:
- ). Introduced Helm Templated resuable functions under dcaegen2-services-common charts; each DCAE components/mS can enable required features via configuration override. Following are current set of features available under dcaegen2-services-common charts

- K8S Secret/Environment mapping
- CMPv2 Certificate support
- Policy Sidecar
- Mount data from configmap through PV/PVC
- Dynamic Topic/feed provisioning
- AAF certificates generation/

distribution            

Under cloudify deployments, Consul is used as central configuration store for all applications. With migration to Helm, the consul dependency is being removed by switching config management through K8S Configmap. This allows application to be deployed standalone in multi/edge cloud without any dependency on central platform components. 

As the solution was completly backward compatible - operator/user have choice to instantiate DCAE either via helm or cloudify or both.