docs: align architecture.md terminology with the data layer#2084
Merged
Conversation
The architecture doc referred to a Scrapers component that no longer exists; the metrics subsystem is the Data Layer (data sources plus extractors). Rename the stale Scrapers references, describe the Source -> Extract -> Attribute lifecycle, and link the canonical upstream llm-d architecture docs the review comment pointed at. Refs: llm-d#1307 Signed-off-by: ChethanUK <chethanuk@outlook.com>
The section body describes the data layer's Source -> Extract -> Attribute lifecycle, but its heading and table-of-contents entry still read Metric Scraping alone, leaving the last stale reference after the Scrapers -> Data Layer rename. Update the heading and its TOC anchor to match. Signed-off-by: ChethanUK <chethanuk@outlook.com>
github-actions
Bot
added
size/M
elevran
reviewed
Jul 20, 2026
|
|
||
| - Scrapers collect metrics (e.g., memory usage, active adapters) | ||
| - Data is injected into the shared datastore for scorers | ||
| - Data sources collect metrics (e.g., memory usage, active adapters) from pods |
Collaborator
There was a problem hiding this comment.
nits:
From an architecture perspective, the data sources periodicallt collect different kinds of data, not only metrics.
For example a models data source periodically lists /v1/models to determine the model/LoRA hosted by the engine.
The data layer defines several different types of source, not just "scarpers". There is an endpoint change notification source, a generic k8s change notification source, an endpoint discovery source, ...
Not sure how detailed this doc needs to be.
elevran
previously approved these changes
Jul 20, 2026
elevran
left a comment
elevran
left a comment
Collaborator
There was a problem hiding this comment.
/approve
/hold for nits
Collaborator
|
@chethanuk would you like to address the nits or should we merge as is (please cancel the hold to indicate)? |
Review feedback on llm-d#2084: sources also poll served models via /v1/models and include notification-based types, not only metric scrapers. Signed-off-by: ChethanUK <chethanuk@outlook.com>
elevran
approved these changes
Jul 22, 2026
elevran
enabled auto-merge (squash)
July 22, 2026 13:50
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What type of PR is this?
/kind documentation
What this PR does / why we need it:
docs/architecture.mddescribed a "Scrapers" component that no longer exists in thecode; the metrics-collection subsystem is now the Data Layer (data sources plus
extractors under
pkg/epp/framework/plugins/datalayer/**). This addresses #1307 byaligning the doc's terminology and cross-links with the current code and the upstream
llm-d/llm-d architecture docs:
section heading, Overview, Core Goals, Routing Flow).
flowchart LR S[Data Sources<br/>collect raw signals from pods] --> E[Extractors<br/>transform into typed attributes] E --> A[Endpoint attributes<br/>in the shared datastore] A --> Sc[Scorers read attributes]upstream canonical" pointers (scheduling, configuration, datalayer).
Scope decision: this PR does the terminology + upstream-links alignment as one
coherent unit. Deeper content reconciliation the issue could also be read to want -
the single-
InferencePool/single-EPP"Current Assumptions", the routing-flownarrative versus upstream
scheduling.md, and the config examples - is deliberatelyleft out. Those are substantive and, in the single-pool case, currently accurate for
this repo's code, so they warrant separate discussion rather than a blind rewrite to
match upstream prose. Divergences that are correct for this repo (default-parser
list, flow-control policy names) were re-verified against local code and left
unchanged.
Which issue(s) this PR fixes:
Part of #1307
Release note (write
NONEif no user-facing change):