[Enhancement][opensearch] Add global support for common values

[mkhpalm]

Is your feature request related to a problem? Please describe.

Add support for some values being read from the global context.

Describe the solution you'd like

I think the role based reusable chart that currently exists is a good approach for opensearch. But if that chart was able to read common (to the cluster) values from global then an umbrella chart could be made to stand up an entire cluster with a single helm release. Its also useful if somebody doesn't want an umbrella chart but just wants to re-use some cluster environment config to all the different roles they are deploying. (e.g. -f common.yaml -f role-values.yaml)

https://helm.sh/docs/chart_template_guide/subcharts_and_globals/

Some specific values that would be nice to define in global

• nameOverride
• clusterName
• dockerRegistry # <-- Already in the current chart - https://github.com/opensearch-project/helm-charts/pull/70
• config
• secrets

Describe alternatives you've considered

There are always operators which are sometimes nice but often have their own k8s cluster wide pitfalls for end users.

Additional context

Assuming the opensearch chart supported global for repetitive release defaults. A Chart.yaml for an opensearch-cluster umbrella chart might looks something like:

apiVersion: v2
name: opensearch-cluster
description: A Helm chart for Opensearch
type: application
version: 1.2.3
appVersion: "1.2.3"
dependencies:
- name: opensearch
  version: ~1
  repository: https://opensearch-project.github.io/helm-charts/
  condition: master.enabled
  alias: master
- name: opensearch
  version: ~1
  repository: https://opensearch-project.github.io/helm-charts/
  condition: data.enabled
  alias: data
- name: opensearch
  version: ~1
  repository: https://opensearch-project.github.io/helm-charts/
  condition: ingest.enabled
  alias: ingest
- name: opensearch
  version: ~1
  repository: https://opensearch-project.github.io/helm-charts/
  condition: remote_cluster_client.enabled
  alias: remote_cluster_client
- name: opensearch-exporter
  version: ~1
  repository: https://opensearch-project.github.io/helm-charts/
  condition: exporter.enabled
  alias: exporter
- name: opensearch-dashboards
  version: ~1
  repository:  https://opensearch-project.github.io/helm-charts/
  condition: dashboards.enabled
  alias: dashboards

Then an oversimplified values example for this umbrella chart would possibly looks something like this:

global:
  clusterName: example1
  config:
    opensearch.yaml: |
      # etc

master:
  enabled: true
  # opensearch sub charts values.yaml accessible here

data:
  enabled: true
  # opensearch sub charts values.yaml accessible here

ingest:
  enabled: false
  # opensearch sub charts values.yaml accessible here

remote_cluster_client:
  enabled: false
  # opensearch sub charts values.yaml accessible here

exporter:
  enabled: false
  # Not sure if there is one yet, but the es exporter currently works if you don't mind the metrics names

dashboards:
  enabled: false
  # opensearch-dashboard sub charts values.yaml accessible here

Note: I realize that a higher level "umbrella" chart is not the point of this ticket. The purpose of this request is just to add global support to the existing opensearch chart. So people who want umbrella charts or just want to use common cluster values files can avoid repeating themselves in role releases.

[peterzhuamazon]

Thanks @mkhpalm for the suggestion, is this a feature you can help contribute? Thanks.

[mkhpalm]

I started looking at this today and noticed Helm may be adopting an enhancement HIP 0016 that implements export-values. Rather than modify the opensearch and opensearch-dashboards charts to support global context a user would be able to push values to the sub-charts from a new parent chart like opensearch-cluster.

• https://github.com/helm/community/pull/242
• https://github.com/helm/helm/pull/10804

If adopted and merged, export-values would likely be a more succinct and straight forward approach to accomplish the same thing. If they do not adopt then I can possibly come up with a PR to support the things that would be best without needing to repeat for an individual cluster's different roles.

[smlx]

Another alternative is to use a tool like helmfile.