feat(DMVP-10317): add analytics component charts - #224
Conversation
🌟 PR Summary: Charting The Course to Brilliance 🌟You folks are awesome for churning out such impeccable work! Let's dive in and see how this update makes us even better! 🚀
The sails are set and the anchors are dropped! It's time for another awesome journey in the sea of coding. Let's keep moving forward and spreading awesomeness everywhere we go! 🚀🌈💡🎉 |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 7378756140
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| scheduler: | ||
| fullnameOverride: redash-scheduler |
There was a problem hiding this comment.
Configure distinct commands for Redash processes
In a default installation, the scheduler and all three worker blocks omit the base chart's command/args, so the Redash image inherits its default server command. Consequently these four Deployments start additional web servers rather than a scheduler or queue workers, leaving scheduled, ad-hoc, and background jobs unprocessed. Set the scheduler/worker commands and each worker's intended queue configuration explicitly.
Useful? React with 👍 / 👎.
| @@ -0,0 +1,59 @@ | |||
| server: | |||
| fullnameOverride: redash-server | |||
There was a problem hiding this comment.
Preserve release scoping in Redash resource names
When two releases are installed in the same namespace—for example, separate tenant instances or a blue/green rollout—these fixed fullnameOverride values make both releases render the same Deployment and Service names. The second installation therefore collides with resources owned by the first unless callers discover and override all five names; leave these overrides empty or incorporate the Helm release name.
Useful? React with 👍 / 👎.
| @@ -0,0 +1,14 @@ | |||
| base: | |||
There was a problem hiding this comment.
Propagate application versions into the base subcharts
The workloads are rendered in the dependency context, but none of the new wrapper value blocks supplies the base chart's appVersion; its label helper therefore renders app.kubernetes.io/version: 0.3.31 on Metabase, PostgREST, and every Redash Deployment instead of the version of the image being run. This produces incorrect version metadata for selectors, inventory, and monitoring, so set appVersion under each base alias to the corresponding application image version.
Useful? React with 👍 / 👎.
|
Addressed the automated review findings in
Validated with |
Summary
Validation
Follow-up
After merge and chart release, terraform-any-analytics will consume the published component-chart versions instead of direct Kubernetes resources.