[milvus] Ability to use user specified ConfigMap for Milvus configuration

[nustiueudinastea]

What this PR does / why we need it:

This PR adds an extra config field which allows users to use a completely custom ConfigMap for configuring Milvus. This is useful for situation where dynamic info needs to be added to the configmap for various reasons (example: configuring storage account ID based on some automatically provisioned resource).

Checklist

[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

• Chart Version bumped
• Variables are documented in the README.md
• Title of the PR starts with chart name (e.g. [mychartname])
• PR only contains changes for one chart

[sre-ci-robot]

Welcome @nustiueudinastea! It looks like this is your first PR to zilliztech/milvus-helm 🎉

[LoveEachDay]

@nustiueudinastea This is not working as you expected. By default milvus helm chart will generate a default.yaml config which will generates all the dependencies configurations like etcd, minio, and message queue. In your pull request, you mount to the same path which will generate side effect.

It's recommended to provide custom configuration through extraConfigFiles.user.yaml instead.

[nustiueudinastea]

@LoveEachDay as far as I understand, it does what I think it does. It allows a user to TOTALLY override the config and provide a fully customised config. This is very useful in some situations because you can't dynamically pass values to the chart, but you can easily create dynamic config maps with custom tailored configs. We have an operator that creates storage accounts for Milvus and that way we can customise the deployment without having to pass values (which are static).

The extraConfigFiles.user.yaml is yet another static way of configuring the chart, by passing values.

[nustiueudinastea]

hey @LoveEachDay any chance we can continue with this?

[haorenfsa]

Hi @nustiueudinastea, it seems reasonable feature to me. 2 things to note:

1. The mounted file better be named as user.yaml which will have the highest priority when being processed by Milvus, thus make sure the configuration is not overwrited ( the default.yaml is to keep the default configs of this Milvus version. )
2. By using subpath, kubelet won't be able to dynamically update it in the Pod. For now you still have to exec into the pod to make the actual dynamic change happen. There will be a patch later to solve this. How does Milvus install by Helm can support dynamic configuration changes when I changed config user.yaml in config map? #94

[haorenfsa]

Oh, by the way, if possible, plz also add an values file in https://github.com/zilliztech/milvus-helm/tree/master/charts/milvus/ci for integration test.

[haorenfsa]

Hi @nustiueudinastea, the changes looks good. Before we could merge it, please resolve the conflicts with current master by git rebase,

[nustiueudinastea]

@haorenfsa ready.

[haorenfsa]

We're getting close. Please also bump the version like other PRs did, check this for example: https://github.com/zilliztech/milvus-helm/pull/89/files @nustiueudinastea

[nustiueudinastea]

@haorenfsa bumped version as well. I bumped the patch version number, even though this PR includes an extra parameter. Should I bump the minor version?

[haorenfsa]

@nustiueudinastea It's OK. Thank you again for the contribution!

[sre-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

Approval requirements bypassed by manually added approval.

This pull-request has been approved by: haorenfsa, nustiueudinastea

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment