docs(rfc): flip RFC 0041 to specified — Perses first, separate repo - #660
Conversation
The decision the drafted RFC asked for, made 2026-07-27: build now, Perses first, all three plugins (Datasource, LogQuery, TimeSeriesQuery — the FinOps dashboard needs time series), in the dedicated ourios-perses-plugin repository; the Grafana datasource stays a cheap ungated follow-up. What changed the §7 "worth doing now?" calculus: RFC 0042 verified live spend aggregation (RFC0042.9), so a dashboard now charts money — the plugin is the demo artifact for the agent-FinOps direction, not a generic API client. Host choice: Grafana wins measured effort, Perses wins posture (Apache-2.0 + CNCF end-to-end vs AGPL, dashboards-as-code, the roadmap's standing §5 commitment). §5 gains RFC0041.1-.6: datasource auth/health, log-panel parity, time-series mapping (NULL aggregates as gaps, never zeros — the RFC 0042 rule shown), runtime schema adaptation via RFC 0032, compatibility declaration CI-exercised against the GHCR image, and the committed FinOps dashboard in this repo as the capstone. §6 maps them to the plugin repo's e2e suite; this repo's CI is untouched. Signed-off-by: Jens Holdgaard Pedersen <Jens@holdgaard.org>
|
Warning Review limit reached
Next review available in: 28 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughRFC 0041 was changed from drafted to specified, documenting a Perses-first implementation in a dedicated repository, concrete acceptance criteria, testing responsibilities, and resolved host and repository decisions. ChangesRFC 0041 Specification
Estimated code review effort: 1 (Trivial) | ~5 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 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: 2
🤖 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 `@docs/rfcs/0041-dashboard-datasource-plugins.md`:
- Line 4: Update the RFC 0041 references in the roadmap sections corresponding
to lines 10-16, 256-260, and 394 to reflect its specified status, populate or
revise the related §5/§6 entries as appropriate, and remove outdated
deferred-work wording so the roadmap matches the RFC.
- Around line 247-253: Update the RFC0041.3 time-series acceptance criterion to
explicitly define bucket boundary semantics, using the same convention
established in RFC 0042 §3.5. State how records exactly on bucket boundaries are
assigned so all plugin implementations produce consistent groups.
🪄 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: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 0e29d160-93f4-4cf5-a427-f52914fae513
📒 Files selected for processing (1)
docs/rfcs/0041-dashboard-datasource-plugins.md
There was a problem hiding this comment.
Pull request overview
Updates RFC 0041 to the specified stage by recording the maintainer’s 2026-07-27 decision (Perses-first, three plugins, separate ourios-perses-plugin repo) and adding the missing §5 acceptance criteria and §6 testing strategy required at this lifecycle gate.
Changes:
- Flip RFC 0041 frontmatter and status callout from
drafted→specified, including a dated decision summary and repository link. - Populate §5 Acceptance criteria (RFC0041.1–.6) and §6 Testing strategy to match the specified-gate expectations.
- Mark key §7 questions as resolved and document the resolutions inline.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
…p sync RFC0041.3 pins RFC 0002 §6.3's bucket boundary rule into the criterion (half-open epoch-aligned [k*w, (k+1)*w), boundary records land in the later bucket, keys are the window start) and splits the placeholders (<k> aggregated, <group_k> series label). RFC0041.5 and .6 rephrase into Given/When/Then per docs/rfcs/README.md — .6 was flagged, .5 had the same shape defect. Roadmap synced with the flip: 2026-07-27 banner entry (RFC 0042 green on live spend, RFC 0041 specified, the #654 endpoint fix, both unreleased breaking changes), ladder rows for 0041/0042, the open-items bullet, and the §5 Perses row; superseded prior-entry claims annotated rather than rewritten. Signed-off-by: Jens Holdgaard Pedersen <Jens@holdgaard.org>
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
Comments suppressed due to low confidence (1)
docs/rfcs/0041-dashboard-datasource-plugins.md:241
- RFC acceptance criteria are expected to be written as normative scenarios with explicit
Given / When / Then / Andleading clauses and an id (docs/rfcs/README.md:59-64). Here RFC0041.1 is written as a single sentence with lowercasewhen/then, and without the established> **Scenario RFC0041.1 — …**structure used across other specified RFCs (e.g. RFC0032 §5). Reformat RFC0041.1–.6 to match the standard scenario style so they’re greppable and consistently test-spec-like.
- **RFC0041.1 (datasource).** Given a Perses instance with the
`OuriosDatasource` plugin configured against a running `ourios-server`
container, when the datasource health/connection path runs, then it
succeeds with and without an RFC 0026 bearer token per the server's mode,
and a wrong-tenant token is surfaced as the API's 403, not swallowed.
A code span split across a blockquote line break leaves unbalanced backticks and renders literally; reflowed so the query stays whole. Signed-off-by: Jens Holdgaard Pedersen <Jens@holdgaard.org>
All six criteria rewritten with bolded Given/When/Then/And sub-bullets per docs/verification.md §2.1, matching RFC 0002's shape. RFC0041.1 now separates the auth modes explicitly: open mode succeeds credential-less; under enforcement a valid token succeeds, a missing token is the API's 401 and a wrong-tenant token its 403 — each a distinct visible error. Signed-off-by: Jens Holdgaard Pedersen <jens@holdgaard.org>
aeb5f31 to
03ca608
Compare
The §1 summary still framed the RFC as asking the host question the specified flip answered; it now states both resolutions and points at §7. Banner: hyphenate the end-to-end modifier and rewrap the over-long line the earlier backtick reflow left (its parentheses were balanced — the wrapping just made that hard to see). Signed-off-by: Jens Holdgaard Pedersen <Jens@holdgaard.org>
RFC 0041 →
specifiedThe
draftedRFC deliberately asked for a decision instead of shipping criteria. The decision is made (maintainer, 2026-07-27), and this PR records it:Build now. Perses first. Three plugins. Separate repo.
ourios-perses-plugin(created + seeded) — the boundary is the stable public query surface; toolchains, cadences, and supply-chain postures are disjoint; standalone plugin repos are the ecosystem convention§5 criteria (new)
RFC0041.1–.5 live in the plugin repo's CI, run against the released
ourios-serverGHCR image (the collector-interop pattern inverted): datasource auth/health incl. the 403 path, log-panel parity with the RFC 0016 response, time-series mapping with NULL aggregates as gaps, never zeros (RFC 0042 §3.5 shown, not re-derived), runtime schema adaptation via the RFC 0032ourios://query-schemaresource, and a CI-exercised minimum-server-version declaration.RFC0041.6 stays in this repo: the committed FinOps dashboard — spend by model over time, token throughput, tool-decision mix — rendering against the dogfood capture. The capstone the host decision was made for.
Invariants
Doc-only. Hazard #6 honoured throughout: the plugins speak the DSL and the RFC 0016/0032 surfaces; nothing DataFusion-shaped leaks.
mdbook buildclean.Summary by CodeRabbit