[Helm Chart] Allow extraVolumes and extraVolumeMounts to be specified in values.

[cccs-tom]

Is your feature request related to a problem? Please describe.
When using Superset as a subchart, it is impossible (known Helm limitation) to "inject" configuration or Python (or other) files using .Files.Get or similar. We would like to be able to define our own ConfigMaps / Secrets / other volumes and mount them into the pods. Other charts we use include extraVolumes and extraVolumeMounts in their templates for this purpose. I would like to add those to the Superset chart.

Describe the solution you'd like
What we have currently implemented (which I would gladly contribute) are extraVolumes and extraVolumeMounts objects at the root of the Superset values. Those are applied to the main containers of all 3 deployments as well as the init-job. The values looks like this:

extraVolumes:
  volume1:
    configMap:
      name: '{{ template "superset.fullname" . }}-custom-config'
  volume2:
    secret:
      secretName: my-secret
extraVolumeMounts:
  volume1:
    mountPath: /mnt/volume1
  volume2:
    mountPath: /mnt/volume2

The key for each object becomes the 'name' field (so the volume and volumeMount keys must match)

Describe alternatives you've considered
The above fits our use case well, but other use cases may not require all volumes to be mounted everywhere. One possible alternative would be to have extraVolumes and extraVolumeMounts objects under supersetNode, supersetWorker, etc. In our specific use case, it would mean some repetition and additional maintenance, but that would be an acceptable solution nevertheless.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. For admin, please label this issue .pinned to prevent stale bot from closing the issue.

[rusackas]

@cccs-tom Should we move this to an "Ideas" thread for further discussion, if it's something you want to keep getting feedback on? Or, would you want to open the PR you mention contributing? CC @craig-rueda for further opinion(s) here.

[cccs-tom]

@cccs-tom Should we move this to an "Ideas" thread for further discussion, if it's something you want to keep getting feedback on? Or, would you want to open the PR you mention contributing? CC @craig-rueda for further opinion(s) here.

@rusackas As far as I'm concerned, it is an oversight that this issue wasn't closed when my PR (#16361) was merged. This solution has been working great for us and our use case(s) require no further improvements at this time...