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/volume2The 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.
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.Getor 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 includeextraVolumesandextraVolumeMountsin 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
extraVolumesandextraVolumeMountsobjects 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: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
extraVolumesandextraVolumeMountsobjects undersupersetNode,supersetWorker, etc. In our specific use case, it would mean some repetition and additional maintenance, but that would be an acceptable solution nevertheless.