We add configuration in our helm chart to set the compute log manager
for the dagster instance. In a subsequent PR, we will enforce type
constraints using the schema.
Details
Details
integration
The following commands template as expected:
helm template test . -s templates/configmap-instance.yaml --set "computeLogManager.type=AzureBlobComputeLogManager" helm template test . -s templates/configmap-instance.yaml --set "computeLogManager.type=GCSComputeLogManager" helm template test . -s templates/configmap-instance.yaml --set "computeLogManager.type=S3ComputeLogManager"
Diff Detail
Diff Detail
- Repository
- R1 dagster
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
| helm/dagster/templates/configmap-instance.yaml | ||
|---|---|---|
| 143–154 | may be best to allow this to remain empty and assume default behavior if not specified | |
| helm/dagster/templates/helpers/_compute-log-manager.tpl | ||
| 36–42 | hmm how does this loading work when some of these options are not set? I believe the config schema is setup for these to be keys to be omitted if there isn't a valid value and may choke | |
Comment Actions
the full custom alternative path is less of a concern since that is unlikely - but I do worry that the config setup does not actually work if attempted to be loaded given the provided test plan
| helm/dagster/templates/configmap-instance.yaml | ||
|---|---|---|
| 140 | may be safer to go with a more generic config section like this so things can be omitted more reasonably | |
| helm/dagster/values.yaml | ||
| 108 | what is the behavior of ~ ? | |
Comment Actions
im still worried about keeping these config fields up to date - but ill let you make the final call
lets get this set up on the demo cluster right away to ensure it works at runtime