Orchestrator Configmap Override

[standrewd]

Description
This adds the ability to use a custom configmap instead of the baseConfig and customConfig in the values files. This allows passing in templated values (Ex: {{ printf "{{ env.TEST_ENV_VAR}}" }} ) to the orchestrator without having to do any escaping.

Example of using a custom configmap

useCustomConfigMap: orch-configmap-custom

Example of generating a configmap from a custom config yaml file.
kubectl create configmap orch-configmap-custom --from-file=maverics.yaml=customConfig.yaml

Example customConfig.yaml

version: 0.0.3

logger:
  level: debug

http:
  address: {{ env.MAVERICS_HTTP_ADDRESS}}

Testing
Tested locally using helm template to validate the output is as expected under different scenarios of values.

Scenario 1
useCustomConfigMap defined

useCustomConfigMap: name: orch-configmap-custom

Results in

volumes:
  - name: orchestrator-config
    configMap:
       name: orch-configmap-custom

Scenario 2
customConfig defined

  customConfig:
    version: 0.0.3

    logger:
      level: debug

Results in

volumes:
  - name: orchestrator-config
    configMap:
       name: release-name-orchestrator-config

Scenario 3
No customConfig defined

Results in

volumes:
  - name: orchestrator-config
    configMap:
       name: release-name-orchestrator-config

Documentation
No additional documentation added.

[wfernandes]

Let's try and find some time tomorrow to pair on this if possible.

We need to update the values.yaml to document this along with the values schema file.
Also lets add some example values in /example-values along with some documentation on how it should be used. For example, should the config map exist before running helm install?

What happens if we specify multiple sources of orchestrator config?

[wfernandes]

Thanks for your work on this @standrewd! lgtm