feat(provisioning): add Cassandra datasource and dashboard provisioning configs - #248
feat(provisioning): add Cassandra datasource and dashboard provisioning configs#248HadesArchitect wants to merge 3 commits into
Conversation
…ng configs Add Grafana provisioning configuration to automatically load the Cassandra datasource and demo dashboard on startup. This enables a containerized setup where Grafana can be fully configured through configuration-as-code.
|
|
Important Review skippedAuto incremental reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
WalkthroughAdds Grafana provisioning configuration files for the Cassandra datasource and demo dashboard, including a new Cassandra Demo Provisioning
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related issues
Poem
🚥 Pre-merge checks | ✅ 4✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (2)
provisioning/dashboards/dashboards.yaml (1)
8-8: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winTurn off UI updates for the provisioned dashboard.
With
allowUiUpdates: true, users can save changes that diverge fromcassandra-demo.jsonand then get overwritten on restart. That is a poor fit for a config-as-code demo.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@provisioning/dashboards/dashboards.yaml` at line 8, The provisioned dashboard is currently configured to allow UI edits, which can let changes drift from the source JSON and be overwritten on restart. Update the dashboard provisioning in dashboards.yaml by changing the allowUiUpdates setting for the provisioned dashboard to disable UI updates, keeping the demo config-as-code aligned with cassandra-demo.json.provisioning/datasources/cassandra.yaml (1)
9-9: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winDisable UI edits on the provisioned datasource.
editable: truelets the datasource drift from the committed provisioning file, which undermines the config-as-code startup flow described in this PR. Preferfalseunless UI mutation is explicitly part of the demo.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@provisioning/datasources/cassandra.yaml` at line 9, The provisioned Cassandra datasource is currently marked editable, which allows UI changes to drift from the committed provisioning config. Update the datasource provisioning entry to disable UI edits by changing the editable setting to false in the Cassandra datasource definition, keeping the config-as-code flow consistent unless the demo explicitly requires mutation.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@provisioning/dashboards/cassandra-demo.json`:
- Around line 300-315: The Cassandra demo dashboard query is still using the old
`loc` contract by selecting `sensor_id, location` and filtering `sensor_id =
${loc}` in the targets query. Update the relevant panel definition in
`cassandra-demo.json` to match the fixed dashboard behavior used by the `loc`
variable: make the `loc` query location-only and change the `target` filter to
compare `location` against `${loc}`. Also apply the same adjustment to the
referenced duplicate panel block so both dashboard definitions stay aligned.
---
Nitpick comments:
In `@provisioning/dashboards/dashboards.yaml`:
- Line 8: The provisioned dashboard is currently configured to allow UI edits,
which can let changes drift from the source JSON and be overwritten on restart.
Update the dashboard provisioning in dashboards.yaml by changing the
allowUiUpdates setting for the provisioned dashboard to disable UI updates,
keeping the demo config-as-code aligned with cassandra-demo.json.
In `@provisioning/datasources/cassandra.yaml`:
- Line 9: The provisioned Cassandra datasource is currently marked editable,
which allows UI changes to drift from the committed provisioning config. Update
the datasource provisioning entry to disable UI edits by changing the editable
setting to false in the Cassandra datasource definition, keeping the
config-as-code flow consistent unless the demo explicitly requires mutation.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: a3f8bc4f-3350-4f73-9bea-490b17386822
📒 Files selected for processing (4)
demo/dashboard.jsonprovisioning/dashboards/cassandra-demo.jsonprovisioning/dashboards/dashboards.yamlprovisioning/datasources/cassandra.yaml
📜 Review details
⏰ Context from checks skipped due to timeout. (2)
- GitHub Check: compatibilitycheck
- GitHub Check: Build, lint and unit tests
🔇 Additional comments (1)
demo/dashboard.json (1)
675-683: LGTM!
| "targets": [ | ||
| { | ||
| "alias": "{{ sensor_id }}:{{ location }}", | ||
| "columnId": " ", | ||
| "columnTime": " ", | ||
| "columnValue": " ", | ||
| "datasource": { | ||
| "type": "hadesarchitect-cassandra-datasource", | ||
| "uid": "cassandra-datasource" | ||
| }, | ||
| "datasourceId": 1, | ||
| "queryType": "query", | ||
| "rawQuery": true, | ||
| "refId": "A", | ||
| "target": "SELECT sensor_id, temperature, registered_at, location FROM test.test WHERE sensor_id = ${loc} AND registered_at > $__timeFrom and registered_at < $__timeTo", | ||
| "type": "timeserie" |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Align the provisioned loc variable with the fixed dashboard contract.
demo/dashboard.json now defines loc as select location ..., but this dashboard still defines it as select sensor_id, location ... and uses it in Line 314 as sensor_id = ${loc}. The provisioned demo will diverge from the fixed dashboard behavior. Mirror the same location-only query here and filter on location instead.
Suggested alignment
- "target": "SELECT sensor_id, temperature, registered_at, location FROM test.test WHERE sensor_id = ${loc} AND registered_at > $__timeFrom and registered_at < $__timeTo",
+ "target": "SELECT sensor_id, temperature, registered_at, location FROM test.test WHERE location = '${loc}' AND registered_at > $__timeFrom and registered_at < $__timeTo",
...
- "definition": "select sensor_id, location from test.sensors_locations where bucket = 'default'",
+ "definition": "select location from test.sensors_locations where bucket = 'default'",
...
- "rawQuery": "select sensor_id, location from test.sensors_locations where bucket = 'default'"
+ "rawQuery": "select location from test.sensors_locations where bucket = 'default'"Also applies to: 622-630
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@provisioning/dashboards/cassandra-demo.json` around lines 300 - 315, The
Cassandra demo dashboard query is still using the old `loc` contract by
selecting `sensor_id, location` and filtering `sensor_id = ${loc}` in the
targets query. Update the relevant panel definition in `cassandra-demo.json` to
match the fixed dashboard behavior used by the `loc` variable: make the `loc`
query location-only and change the `target` filter to compare `location` against
`${loc}`. Also apply the same adjustment to the referenced duplicate panel block
so both dashboard definitions stay aligned.
Thanks CodeRabbit
|
Finally |
1 participant
Add Grafana provisioning configuration to automatically load the Cassandra datasource and demo dashboard on startup. This enables a containerized setup where Grafana can be fully configured through configuration-as-code.
Summary by CodeRabbit