Improve chart ergonomics

[AlecMMiller]

Is your feature request related to a problem? Please describe.
The current Helm chart config is rather decoupled between the configuration of OpenBao via the config string and the kubernetes resource declarations. As one example, in order to configure file-based storage, you need to have

storage "file" {
   path = "/openbao/data"
}

in your config string and also have

dataStorage:
   enabled: true
    mountPath: "/openbao/data"

This requires duplication of the same values and can easily result in invalid configuration (e.g. you aren't using file storage for your storage but you left dataStorage enabled, creating an unnecessary PVC)

Describe the solution you'd like
A pattern used in for example the Tempo Helm chart is to have a config string but make use of templating to generate most of the contents, such as storage backing

https://github.com/grafana/helm-charts/blob/dc7572f3b4d8433e9de5e3a00f521b26234654c5/charts/tempo-distributed/values.yaml#L1266
https://github.com/grafana/helm-charts/blob/dc7572f3b4d8433e9de5e3a00f521b26234654c5/charts/tempo-distributed/values.yaml#L1622

Obviously getting every config possible converted to Helm would be too much work, but I think you could get a lot of low hanging fruit by combining essential config as a template with an "extraConfig" string that gets appended to the end to handle the less common more complex parts.

To go to the storage example, I would think you would have say

storage:
   type: raft
   raft:
      storageClass: my-storage-class
      mountPath: "/openbao/data"

which gets generated into a config template like

{{- if eq .Values.storage.type raft }}
storage "raft" {
  path = "{{ .Values.storage.raft.mountPath}}"
}
{{- end }}

I'd be happy to take a pass at doing this myself, but I wanted to gauge receptiveness rather than just putting in a bunch of work and dropping a PR out of nowhere.

[pree]

Hi @AlecMMiller

thanks for bringing this up, we already had this on our radar, but it's nothing easy to do. Especially with the support for third party / community plugins as the storage backend or even for other parts we really need to think how we want to this, as this would also introduce a breaking change which we would like to avoid as much as possible.

We'll need to discuss this some further before coming to an conclusion.

[AlecMMiller]

Yeah, that all makes sense. I think a decent fallback could be that, for any configurable field, one of the options is type "custom" where you can pass in arbitrary config. E.g for a storage plugin

storage:
   type: custom
   custom:
      name: my-custom-plugin
      config: |
           ...

{{- if eq .Values.storage.type "custom"}}
storage "{{ .Values.storage.custom.name }}" {
{{ .Values.storage.custom.config | indent 2 }}
}
{{- end }}

Or just if the type is set to custom, nothing is added and you just add it to the extraManualConfigs value that gets appended to the end of the config.

One way I see you could avoid making a breaking change is to keep the config values in the chart as is, but because they're already being set through a tpl function anyway, you could have the default value equal say {{ include "openbao.configTemplate" }} so that it only takes effect if you haven't already configured it manually. Another nice side effect of this is that you don't need an extra value to add stuff to the end, the user could just edit it to be in the form

config: |
   {{ include "openbao.configTemplate }}
  
   config "thing" {
      etc etc
   }

Although that does feel a bit hacky to me