Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[DSIP-36][Helm] split application.yaml as configmap to control db/registry #15924

Closed
2 tasks done
pegasas opened this issue Apr 26, 2024 · 0 comments
Closed
2 tasks done
Assignees
Labels

Comments

@pegasas
Copy link
Contributor

pegasas commented Apr 26, 2024

Search before asking

  • I had searched in the DSIP and found no similar DSIP.

Motivation

Like https://github.com/apache/dolphinscheduler/blob/dev/deploy/kubernetes/dolphinscheduler/templates/configmap.yaml and discuss in #15922 (comment),

We could put application.yaml into configmap, and make some important items of application.yaml as variables and access them through values.yaml.

mainly focus on datasource & registry configuration in stage 1

involves #14102 and #15473

Design Detail

We could put application.yaml into configmap, and make some important items of application.yaml as variables and access them through values.yaml. For example api server, alert server and master server all need access to db and there are db related configs in the application.yaml for all of them. So you may put db related configs in values.yaml, and share those configs across different application.yaml for alert server, api server and master server. The same for registry related configs.

Compatibility, Deprecation, and Migration Plan

1.split api/master/worker/alert application into configmap, keep the same as docker
2.put datasource & registry configuration into values.yaml and make it disable
3.make it enable
4.remove old configuration

Test Plan

Test by UT and E2E

Code of Conduct

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants