[RSS Phase 2] DIRAC legacy integration

[aldbr]

Goal

DIRAC's ResourceStatus and SiteStatus singletons consume resource status from diracx instead of the legacy RSS RPC service. Once this phase is complete, the legacy RSS read path is no longer exercised in production, even though the RPC service itself stays up until phase 3 (write API) lands.

Consumers

Two singleton helpers wrap ResourceStatusClient (RPC) with a 300s in-memory cache:

• ResourceStatus — returns status for Storage Elements (4 access types), Computing Elements, and FTS. Used by StorageFactory, SiteDirector, FTS3Utilities, admin scripts, and others.
• SiteStatus — returns site availability. Used by SiteDirector, JobScheduling, Matcher, and others.

Both also expose write methods used by admin scripts and agents. All consumers go through the singletons, so migrating the singletons' backend is transparent to them.

Can DIRAC work with the simplified (binary) status?

Phase 1 serves a binary AllowedStatus / BannedStatus model (Active / Degraded → allowed, everything else → banned).

A review of the DIRAC consumers suggests the binary model is compatible with every core read-path consumer: they either check status in ("Active", "Degraded") or status != "Banned", which is exactly the binary split. A few minor adaptations are still expected on the consumer side.

Sub-issues

graph LR
    A[A. Adapt DIRAC consumers<br/>to binary status model] --> C[C. Wire adapter into singletons<br/>+ feature flag + integration tests]
    B[B. Read adapter<br/>diracx RSS calls + translation] --> C

    style A fill:#c3e6cb
    style B fill:#c3e6cb

Loading

Green = can start once phase 1 is merged (parallel, independent).

• A. Adapt DIRAC consumers to the binary status model
• B. Read adapter: diracx RSS calls + response translation
• C. Wire adapter into singletons + feature flag + integration tests