ONAP Upgrade using OOM framework Min Sang Yoon

ONAP Upgrade using OOM framework Min Sang Yoon - TATA Communications Ahmad Khalil - TATA Communications

Contents • Overview • ONAP OOM Upgrade Issues • Upgrade Approach & Solution • Demo • Lesson Learned & Challenges • Q&A

Overview • TATA Communications has been evaluating ONAP as E 2 E service orchestrator for deployment since Beijing release • Service providers’ use cases usually are specific and different. TATA communications had started developing and implementing its own ONAP artifacts to support its own L 2 service orchestration, which was completed in El-Alto release (Dublin release was skipped) • One of the main key issues that is still unresolved is the ONAP upgrade. This is an important part of the evaluation of the ONAP deployability to ensure graceful upgrade of ONAP without risking service data and artifacts loss • As of today, ONAP helm chart does not support graceful upgrade for all components. • We share our experience of how we solved issues and enabled graceful upgrade of ONAP using Helm Hook framework • We will demo upgrading Maria. DB and SDNC (including DG-Builder and Network-Name. Gen) from Frankfurt to Guilin release

Upgrade Approach & Solution • • • ONAP OOM framework helps deploy microservices on K 8 S using Helm chart Helm is a package manager of K 8 S which allows to manage, deploy, delete, upgrade and rollback microservices using helm charts Current major ONAP components do not support rolling upgrade using helm upgrade feature because of following issues – Residual ‘Persistent. Volumes. Claim’ and ‘Persistent. Volume’ from statefulset prevents deployment of new release – Immutable field prevent helm to run ‘helm deploy’ or ‘helm upgrade’ – Loss of data during the upgrade To solve this issue, we used Helm hook mechanism for the upgrade Helm hook mechanism allows chart developers to intervene at certain point in an application lifecycle (pre-install, post-install, pre-upgrade, post-upgrade, etc…) We applied helm hooks to create a temporary pod which runs scripts to solve upgrade issues during the lifecycle of upgrade Statefulset Application Architecture Service Statefulset POD-1 POD-2 PVC-1 PVC-2 PV-1 PV-2

Demo • DEMO Maria. DB and SDNC Upgrade

Lesson Learned & Challenges • • • Using Helm hook framework, TATA communications developed helm chart to support graceful release upgrade for all major components. The upgrade process takes around 2 hours in our environment because of data backup and restoration time We were able to upgrade gracefully from El-Alto to Frankfurt release using the developed helm chart for the 11 main components that we use in our use case As this is a modified ONAP branch using internally developed helm charts, for every new ONAP release, we need additional development effort to adjust to new release helm chart. ONAP uses heterogeneous database for each component. Data backup and restoration is challenging for each component during the upgrade process Helm chart development progress: – Maria. DB – completed. – Cassandra – completed. – Postgre. Sql – completed. – Dgbuilder – completed – Network-Name-Gen - completed – SDNC – completed. – AAI – completed. – SDC - completed – DMAAP – completed – DCAE - completed – SO – Suspended(https: //jira. onap. org/browse/SO-3421)

Q&A