nv-redfish

A modular Redfish client stack for Rust.

Repository structure

• core: Semantic-unaware foundation used by code generated from CSDL

  • Primitives and traits: Bmc, EntityTypeRef, Expandable, NavProperty<T>, Action<T,R>, ODataId, ODataETag, EdmDateTimeOffset, EdmDuration, Empty
  • Optional HTTP client behind the reqwest feature (enabled by default) in core::http (ReqwestClient, HttpBmc)
  • Goal: provide the minimum building blocks for generated code; no service-specific logic

• redfish: High-level ergonomic wrappers over generated Redfish schema types

  • Feature-gated services (enable only what you need): e.g., accounts (implemented), events (planned)
  • OEM extensions planned, also under features
  • Patch support (redfish::patch_support) to handle vendor quirks while maintaining compatibility
  • Uses generated types included via redfish::schema (autogenerated by the CSDL compiler)

• csdl-compiler: CSDL (OData) schema compiler and Rust code generator

  • Reads Redfish (and OEM) CSDL XML, compiles a subset, and generates Rust code
  • Two primary compilation modes:
    • Compile: compile a subset rooted at specific singletons (e.g., Service)
    • CompileOem: compile OEM schemas and include them in the root set
  • Entity type inclusion can be controlled with wildcard patterns; only needed types are compiled
  • The generator produces Rust modules and types consumed by the redfish crate
  • CLI: csdl-compiler with subcommands in csdl-compiler/src/commands.rs

How the pieces fit together

1. Choose features in redfish (services, OEM flags). The selected features determine which schemas to include (see features.toml) and which high-level wrappers are built.
2. The build uses csdl-compiler to generate only the required schema types into the redfish crate (via build.rs), keeping the binary lightweight.
3. The high-level redfish APIs (e.g., ServiceRoot, accounts) operate over the generated types and the core primitives.
4. Provide a Bmc implementation. With core’s reqwest feature, use HttpBmc<ReqwestClient>; otherwise, plug in your own transport.

Feature flags

• core:
  • reqwest (default): enables the HTTP client implementation
• redfish:
  • accounts: AccountService wrappers (implemented)
  • events: Events service wrappers (planned)
  • OEM extensions: planned per vendor, also feature-gated

Example

Minimal shape (pseudocode):

use nv_redfish_core::http::{HttpBmc, ReqwestClient};
use nv_redfish_core::bmc::BmcCredentials;
use nv_redfish_redfish::ServiceRoot;
use std::sync::Arc;
use url::Url;

# async fn run() -> Result<(), Box<dyn std::error::Error>> {
let bmc = Arc::new(HttpBmc::new(
    ReqwestClient::new()?,
    Url::parse("https://192.168.1.100")?,
    BmcCredentials::new("admin".into(), "password".into()),
));

let root = ServiceRoot::new(Arc::clone(&bmc)).await?;

// If `accounts` feature is enabled:
// let accounts = root.account_service().await?;
// let collection = accounts.accounts().await?;
// println!("{}", collection.odata_id());
# Ok(())
# }

Goals

• Be as lightweight as possible:
  • Compile only schemas referenced by enabled features (features.toml driven).
  • Keep the core minimal and transport-agnostic.
• Support a variety of vendors compatibly:
  • Feature-gated OEM extensions.
  • Patch support for schema deviations in real-world BMCs.

License

See workspace Cargo.toml.

This project includes Redfish schema files from DMTF’s Redfish-Publications repository, licensed under the BSD-3-Clause license.

This project includes Swordfish schema files from SNIA, licensed under the BSD-3-Clause license

Contributing

Please see CONTRIBUTING.md for details.