aspexdaniel commented on PR #11508: URL: https://github.com/apache/dolphinscheduler/pull/11508#issuecomment-1236499734
> @rickchengx now, in the master, if the user wants to modify some configurations, they can just `kubectl create configmap master-server --from-file=/path/to/the/master/application.yaml` or `kubectl create configmap worker-server --from-file=/path/to/the/worker/application.yaml`, etc.. Does this solve your problem? > > ALso, the benefit of 👆 compared to your changes, is that, users can just provide a patch config without copying the whole `application.yaml`, this is convenient when upgrading to a newer version so users don't need to compare the 2 config files and cherrypick the new config section. @kezhenxu94 you only created these configmaps, but not mounting them into deployment/statefulset, which will not be seen by DS pods, right? I agree with your point users do not need to specify all configs within values.yaml, can we refer back to what 2.x version did: 1. passing ENV variables at chart values.yaml (which are not picked up directly by DS programs) 2. in all DS docker conainter entrypoint, start.sh refers to `startup-init-conf.sh`, which replaces all ENV variables into conf files, see https://github.com/apache/dolphinscheduler/blob/2.0.6-release/docker/build/startup-init-conf.sh#L133 3. so, if user changes any single ENV value in values.yaml ( e.g. `helm install xxx`) the startup-init-conf.sh will pickup the ENV and replace into actual conf files, which are then used by DS programs after startup -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
