We currently use GitOps practices and manage the workspace.yaml configmap outside of the helm chart and by a different team. Currently we have an issue that we cant deploy the helm chart unless this team has created the configmap. Which doesnt really work for our system DR strategy (we setup the platform first before other teams deploy their workloads).
It would be really helpful if we could have the ability to set the configmap as optional so that we could still deploy dagster without the dependency on the other team, and once they have deployed their code locations, we could just restart the pods to load the configmap. Its not ideal, but would atleast stop a heavy dependency between our two teams.
Ideas of implementation
I assume all we would have to do is to add a value here
With:
{{- if $userDeployments.enabled }}
- name: dagster-workspace-yaml
configMap:
name: {{ include "dagster.workspace.configmapName" . }}
optional: {{ .Values.workspace.externalConfigMapOptional }}
{{- end }}
The default behaviour could still be false and the naming of the variable can conform to whatever is best for the helm chart.
Additional information
No response
Message from the maintainers
Impacted by this issue? Give it a 👍! We factor engagement into prioritization.
What's the use case?
We currently use GitOps practices and manage the
workspace.yaml
configmap outside of the helm chart and by a different team. Currently we have an issue that we cant deploy the helm chart unless this team has created the configmap. Which doesnt really work for our system DR strategy (we setup the platform first before other teams deploy their workloads).It would be really helpful if we could have the ability to set the configmap as optional so that we could still deploy dagster without the dependency on the other team, and once they have deployed their code locations, we could just restart the pods to load the configmap. Its not ideal, but would atleast stop a heavy dependency between our two teams.
Ideas of implementation
I assume all we would have to do is to add a value here
With:
The default behaviour could still be false and the naming of the variable can conform to whatever is best for the helm chart.
Additional information
No response
Message from the maintainers
Impacted by this issue? Give it a 👍! We factor engagement into prioritization.