/
Externalizing ONAP DBs to a separate namespace

Externalizing ONAP DBs to a separate namespace

Internship Projects/Mentors





Title

Externalizing ONAP DBs to a separate namespace

Status

Approved by TSC

Difficulty

Medium / High (depending on number of hardcoded credentials he or she finds in ONAP dockers)




Description 

ONAP can be considered as a huge, multi-language business application that is deployed using Helm in containers on Kubernetes. As every application it needs the place to store its persistent data - databases and ONAP actually needs a lot of them. Currently they are all deployed by components that are using them without any flexibility for the use to provide his own DB or use some operator FW to manage them. Additionally choice which components may share the same instance of the DB engine is very limited.

We would like to improve the current situation by implementing a two staged deployment:

1) Deploy all required DB engines (can be done using community charts or any user chart)

2) Deploy ONAP components & configure them to make use of those engines



This would allow use to basically bring his own database for ONAP no matter if it is running in the same k8s cluster or it has been provided by some DBaaS solution. Additionally it makes our deployment more modular and configurable thus may result in significant footprint savings.

Additional Information

High Level vision for OOM

Repository: https://github.com/onap/oom

Learning Objectives

  • Take a part in extending (both code & design) current ONAP installer

  • Gain experience in working with a huge, distributed application on kubernetes

  • Learn on CI/CD practices that we use in gating

  • Opportunity to make an impact and create a piece of software that will be used by all top CSPs to deploy ONAP

Expected Outcome

Two step ONAP installer with at least one (preferably all of them) DB externalized to a separate namespace

Relation to LF Networking 

ONAP

Education Level

No preference on education. Need just a smart person who is not affraid to get his or her hands dirty with dozen of helm charts that we have

Skills

  • Docker

  • Kubernetes

  • Helm

  • Scripting

  • At least rough idea about various types of DBs

Future plans

There are other components that should be migrated to separate namespaces in order to provide a fully configurable ONAP deployment.

Preferred Hours and Length of Internship

both 40/12 and 20/24 are fine - no preference here.

Mentor(s) Names and Contact Info

Krzysztof Opasiak <k.opasiak@samsung.com>





Related content

2021-02-03 - ONAP: ONAP Upgrade using OOM framework
2021-02-03 - ONAP: ONAP Upgrade using OOM framework
More like this
2023-11 - ONAP: ONAP Streamlining Evolution - for individual ONAP component build and deployment thru CD
2023-11 - ONAP: ONAP Streamlining Evolution - for individual ONAP component build and deployment thru CD
More like this
2023-11 - ONAP: ONAP Architecture Evolution - Streamlining Process
2023-11 - ONAP: ONAP Architecture Evolution - Streamlining Process
More like this
2022 LFN Workshop - EMCO and ONAP On-boarding and use case alignment
2022 LFN Workshop - EMCO and ONAP On-boarding and use case alignment
More like this
2020-10-15 - ONAP: Guilin CNF improvements overview
2020-10-15 - ONAP: Guilin CNF improvements overview
More like this
WS05: ONAP Orchestration and Testing
WS05: ONAP Orchestration and Testing
More like this