Skip to content

ResourceStatusSource + route #839

@aldbr

Description

@aldbr

Description

Wire the data models #837 and caching infrastructure #838 together: implement ResourceStatusSource(CacheableSource) that reads from ResourceStatusDB and serves resource status through a new config route.

Scope

  1. ResourceStatusSource: a CacheableSource subclass that:

    • Reads from ResourceStatusDB (Site + Resource status tables)
    • Translates DB status values (Active/Degraded/Banned/...) to the binary Pydantic models (AllowedStatus/BannedStatus)
    • Implements latest_revision() — e.g. hash of current status snapshot, or max DateEffective/LastCheckTime
    • Implements read_raw() — returns the full status dict per resource type and VO
  2. Route: new endpoint under the config router:

    /config/resource-status/storage?vo={inferred_from_credentials} -> dict[str, StorageElementStatus]
    

    Equivalent endpoints for compute and site status.

  3. Access policy: any authenticated user can read (similar to current config endpoint being @open_access, but scoped to the user's VO).

  4. Integration tests: verify end-to-end flow from DB data to API response, including HTTP caching headers (ETag / 304 Not Modified).

Technical details

  • ResourceStatusSource lives in diracx-core/src/diracx/core/config/ or a new diracx-core/src/diracx/core/rss/ package
  • VO is inferred from the client's token — no need to expose all VOs
  • HTTP caching (ETag, Last-Modified, 304) should reuse the same pattern as the config endpoint
  • Dependency injection: ResourceStatusSource needs access to ResourceStatusDB — design the wiring so it fits the existing DI patterns

Reference

  • Chris's route proposal: #790 comment
  • Config router pattern: diracx-routers/src/diracx/routers/configuration.py
  • DI patterns: diracx-routers/src/diracx/routers/dependencies.py

Acceptance criteria

  • ResourceStatusSource(CacheableSource) reads from ResourceStatusDB and produces Pydantic status models
  • Route serves storage/compute/site status per VO
  • HTTP caching headers (ETag, 304 Not Modified)
  • Access policy: authenticated users, scoped to their VO
  • Integration tests covering the full read path

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions