Include yorkie-mongodb to yorkie-cluster Helm Chart

[krapie]

Description:

Include yorkie-mongodb to yorkie-cluster Helm chart as subchart.

Recently we have removed mongoDB subchart in yorkie-cluster while introducing yorkie-mongodb. Because of this, we now need to install both yorkie-cluster and yorkie-mongodb to fully setup Yorkie cluster, which is a bit cumbersome.

• Add Helm chart for MongoDB sharded cluster #769

Why:

To fully provide Yorkie cluster feature including DB layer when installing yorkie-cluster Helm chart.

[hyun98]

@krapie Hi, Can I try this issue? :)

[krapie]

@hyun98 Sure! We need to think about how to gracefully add mongoDB into Yorkie cluster.

I think there can be several approaches, such as options to select between standalone or sharded mongoDB. Or we can introduce new full version of Yorkie server system Helm chart that contains all components of Yorkie cluster.

[hyun98]

@krapie I thought of a solution to the issue I briefly mentioned at the opening up last week.

The yorkie-mongodb needed the namespace factor, so it was not easy to be included in the subchart of the yorkie-cluster.
To solve this, I checked the origin mongodb-sharded helm chart code and found out the cause.

Found a problem with the _helers.tpl part inside the mongodb-sharded chart.

If you look at the mongodb-sharded.configServer.primaryHost setting part of the 32nd line, if externalHost is not used, the namespace part of the configsvr domain is set to .Release.Namespace.

For this reason, when the mongodb-sharded chart was installed, an additional namespace factor must be added to operate successfully even though the 'overrideNamespace' value was set.

So, I brought the entire mongodb-sharded chart and tried to modify and use only the mongodb-sharded.configServer.primaryHost part, and I checked the �successful operation during the minikube test.

Additional matters to be carried out are as follows. Since it takes some time for the mongodb-sharded pods to be fully activated, there is an issue that the yorkie pod stays in the CrashLoopBackOff state for a while, so I'm going to solve it. (Finally, when the mongodb-shard is running, the yorkie is also distributed successfully.)
I don't think it looks good to show in the 'CrashLoopBackOff' state, so I'm thinking about whether need the yorkie pods's waiting job.

[krapie]

@hyun98 Thank you for your deep investigation!

So, I brought the entire mongodb-sharded chart and tried to modify and use only the mongodb-sharded.configServer.primaryHost part, and I checked the successful operation during the minikube test.

So we need to leverage customized mongodb-sharded chart to integrate with yorkie-cluster chart?

I don't think it looks good to show in the 'CrashLoopBackOff' state, so I'm thinking about whether need the yorkie pods's waiting job.

How about using initContainer in Kubernetes to make Yorkie server pod wait MongoDB pods to be ready?

[hyun98]

First, I tested the stable installation of yorkie-cluster using initContainer. thank you @krapie

Currently, mongodb-sharded charts seem difficult to use as subcharts. So, I have raised an issue with bitnami/mongodb-sharded.

It seems that the way of importing the entire mongodb-sharded chart and modifying only part of it is not good for maintenance.
Whereas, it seems best to merge my PR in the bitmani chart and upload the chart version. But the downside is that I don't know when my PR will be merged.

Therefore.. how about putting this issue on hold for a while?

[krapie]

@hyun98 Sure, let's hold this PR for now.
Thank you for your contribution so far! 👍🏼

[hyun98]

@krapie
The PR I posted on mongodb-sharded has been merged, and if we use mongodb-sharded chart version 8.3.7 or higher, we will be able to use the mongodb-sharded chart without any namespace issues.

[krapie]

@hyun98 Great!! Feel free to open following PR 😄