Problem and goal
Help operators inspect Rook's reported Ceph health details and block-pool configuration alongside Kubernetes workloads. Radar can browse the CRDs generically, and Rook printer columns already expose some summary fields; the gap is dedicated detail/interpretation, not first visibility.
Scope and considerations
- Start with
ceph.rook.io CephCluster and CephBlockPool tables/drawers: controller-reported health/reasons and reconciliation state, plus relevant cluster/storage and replicated or erasure-coded pool configuration.
- Keep configuration separate from observed health. Desired replica count or failure domain does not prove actual durability/availability. Show health reasons and
status.ceph.lastChecked where available; HEALTH_WARN is a warning, not automatically a critical incident or harmless. Missing/stale status must remain explicit.
- Start from Kubernetes API data only. No Ceph dashboard, CLI/toolbox commands, metrics backend, OSD management, storage mutations or backup/restore workflows.
- Relationship enrichment may follow where CSI StorageClass parameters and object references support an unambiguous association. Don't infer relationships from similar names or require topology for the first useful PR.
Follow the integration guide, considering resource views, controller-specific Issues and existing MCP summaries. Avoid exposing credentials. Recommended split: cluster/pool presentation and status first; storage relationships later. Other Ceph CRDs are follow-ups.
Ideally you operate Rook/Ceph and can validate against a real installation. State Rook/Ceph versions; include sanitized fixtures for healthy/warning/error and absent/stale status, and real-environment screenshots. Exercise restricted access and unavailable references where relevant; don't induce storage failures on production clusters.
CephCluster docs · CephBlockPool docs
Problem and goal
Help operators inspect Rook's reported Ceph health details and block-pool configuration alongside Kubernetes workloads. Radar can browse the CRDs generically, and Rook printer columns already expose some summary fields; the gap is dedicated detail/interpretation, not first visibility.
Scope and considerations
ceph.rook.ioCephCluster and CephBlockPool tables/drawers: controller-reported health/reasons and reconciliation state, plus relevant cluster/storage and replicated or erasure-coded pool configuration.status.ceph.lastCheckedwhere available; HEALTH_WARN is a warning, not automatically a critical incident or harmless. Missing/stale status must remain explicit.Follow the integration guide, considering resource views, controller-specific Issues and existing MCP summaries. Avoid exposing credentials. Recommended split: cluster/pool presentation and status first; storage relationships later. Other Ceph CRDs are follow-ups.
Ideally you operate Rook/Ceph and can validate against a real installation. State Rook/Ceph versions; include sanitized fixtures for healthy/warning/error and absent/stale status, and real-environment screenshots. Exercise restricted access and unavailable references where relevant; don't induce storage failures on production clusters.
CephCluster docs · CephBlockPool docs