Skip to content

redfish

Jump to bottom
Pola, Sudhir edited this page May 25, 2026 · 1 revision

Redfish Support in DMT Console

📋 Table of Contents

📖 Introduction

DMTF’s Redfish® is a standard designed to deliver simple, secure management for converged, hybrid IT and the Software Defined Data Center (SDDC). Both human-readable and machine-capable, Redfish leverages common Internet and web services standards to expose information directly to the modern tool chain.

⭐ Key Characteristics of Redfish

  1. RESTful Architecture - Uses standard HTTP/HTTPS methods (GET, POST, PATCH, DELETE)
  2. Standardized Data Models - Common schema for representing hardware components with consistent naming conventions across vendors and well-defined resource relationships.
  3. Security-First Design - Built-in authentication and authorization mechanisms, HTTPS/TLS encryption for all communications, Role-based access control (RBAC), and Event-driven security notifications

🔗 Redfish API Structure

The Redfish API follows a hierarchical resource model organized around well-defined endpoints:

/redfish/v1/                             # Service Root
├── Systems/                             # Computer Systems
│   ├── 1/                               # Specific System
│   │   ├── Processors/                  # CPU Information
│   │   ├── Memory/                      # Memory Modules
│   │   ├── Storage/                     # Storage Controllers
│   │   ├── NetworkInterfaces/           # Network Adapters
│   │   └── Actions/                     # Available Actions
├── Chassis/                             # Physical Chassis
├── Managers/                            # Management Controllers
├── AccountService/                      # User Account Management
├── SessionService/                      # Session Management
├── EventService/                        # Event Subscriptions
└── UpdateService/                       # Firmware Updates

🎯 Redfish in the DMT Context

The DMT offers Redfish as a standards-compliant management interface by translating the Redfish API to WS-MAN API's (where applicable) to provide unified access to Intel Active Management Technology (AMT) enabled devices. This integration of Redfish standards into existing DMT architecture offers several advantages:

  1. Standardized Device Management - Common API interface for all managed devices and simplified client integration for third-party tools
  2. Enterprise Integration - Integration with existing enterprise management tools, support for bulk operations across multiple devices, standardized reporting and monitoring capabilities
  3. Future-Proof Architecture - Built on industry standards that continue to evolve, support for emerging hardware features through schema extensions, compatibility with next-generation management tools

⚙️ Redfish usage from DMT

The DMT Console exposes Redfish APIs as additional endpoints alongside the existing DMT REST APIs, effectively acting as a Redfish Aggregator for all Intel Active Management Technology (AMT) enabled devices under its management. This architecture provides a standardized Redfish interface while maintaining backward compatibility with existing DMT workflows.

📋 Device Onboarding Prerequisite

Important: Before a device can be accessed via Redfish APIs, it must be onboarded to the DMT Console using existing DMT procedures as described in the DMT Enterprise Device Activation, Addition.

Once onboarded through DMT, the device becomes available via both:

  • DMT REST APIs - Immediate availability for existing workflows
  • Redfish APIs - Standards-compliant access through /redfish/v1/ endpoints

Both API sets operate on the same underlying device infrastructure, with DMT serving as an intelligent Redfish Aggregator that:

  • Translates between AMT device capabilities and Redfish data models
  • Aggregates multiple AMT devices into a unified Redfish service root
  • Normalizes device responses to conform to DMTF Redfish schemas
  • Proxies Redfish requests to appropriate AMT devices
  • Maintains consistent authentication and authorization across both API sets

🔄 Redfish Workflow Sequence

The following sequence diagram illustrates the generic workflow for any Redfish API request through the DMT Console aggregator:

sequenceDiagram
    autonumber
    participant Client as Redfish Client
    participant DMT as DMT Console
    participant AMT1 as AMT Device 1
    participant AMT2 as AMT Device 2

    Note over DMT,AMT2: Prerequisites: Device Onboarding (must be completed first)

    Note over Client,AMT2: Generic Redfish API Operations (after onboarding)

    Client->>DMT: Redfish API Request
    alt End-points other than ServiceRoot, Metadata
      DMT->>DMT: Authenticate (HTTP Basic Auth)
    end
    DMT->>DMT: Parse Redfish resource path

    alt Device-specific resources (Systems)
        DMT->>DMT: Identify target devices
        DMT->>AMT1: Retrieve device data (WS-MAN Requests)
        DMT->>AMT2: Retrieve device data (WS-MAN Requests)
        AMT1-->>DMT: Device-specific response (WS-MAN Responses)
        AMT2-->>DMT: Device-specific response (WS-MAN Responses)
        DMT->>DMT: Transform device data to DMTF Redfish schema
        DMT->>DMT: Aggregate device collection
    else Service-level resources (SessionService, AccountService, EventService)
        DMT->>DMT: Process service-level operation
        DMT->>DMT: Generate service response from DMT configuration
        Note over DMT: No device interaction required
    end

    DMT->>DMT: Apply Redfish resource formatting
    DMT-->>Client: DMTF-compliant Redfish response
Loading

Device Mapping Example

When a device is onboarded to DMT, it becomes accessible via both API paradigms:

DMT REST API Access:

# Get device information via DMT API
GET /api/v1/devices/{device-uuid}
Authorization: Bearer {jwt-token}

Redfish API Access:

# Get same device via Redfish API
GET /redfish/v1/Systems/{device-uuid}
Authorization: Basic {base64(<username:password>)}

Both endpoints provide access to the same AMT device, but with different data representations:

  • DMT API returns DMT-specific JSON structure
  • Redfish API returns DMTF-compliant ComputerSystem schema

Redfish Aggregation Workflow Example

The following sequence diagram illustrates how the DMT Console aggregates multiple onboarded AMT devices into a unified Redfish Systems collection:

sequenceDiagram
    autonumber
    participant Client as Redfish Client
    participant DMT as DMT Console
    participant AMT1 as AMT Device 1
    participant AMT2 as AMT Device 2

    Note over DMT,AMT2: Prerequisites: Device Onboarding (must be completed first)

    Note over Client,AMT2: Redfish API Operations (after onboarding)

    Client->>DMT: GET /redfish/v1/Systems/
    DMT->>DMT: Query onboarded devices
    DMT->>AMT1: Get system information (WS-MAN APIs)
    DMT->>AMT2: Get system information (WS-MAN APIs)
    AMT1-->>DMT: AMT-specific response (WS-MAN APIs)
    AMT2-->>DMT: AMT-specific response (WS-MAN APIs)

    DMT->>DMT: Transform to Redfish schema
    DMT->>DMT: Aggregate device collection
    DMT-->>Client: Redfish Systems Collection
Loading

✅ Prerequisites Summary

Before utilizing Redfish APIs for any AMT device:

✅ Required Steps:

  1. Device must be discoverable on the network
  2. Device must have AMT enabled and properly configured
  3. Device must be onboarded through DMT's existing procedures
  4. Device must be healthy and responsive in the DMT console
  5. User must have valid authentication to the DMT console

This approach ensures that all existing DMT investments and procedures remain valuable while providing the additional benefit of standards-compliant Redfish access to the same managed infrastructure.

🏛️ Architecture and Design

The DMT Console implements Clean Architecture principles to ensure modularity, scalability, and maintainability. The Redfish feature is architected as a modular component that maintains strict adherence to Clean Architecture boundaries while leveraging shared infrastructure components.

🏗️ Modular Architecture Design

The Redfish implementation is built as a separate module that works alongside the main DMT system:

  1. 🔌 Independent Operation: Redfish works on its own while using DMT's shared services (like logging and authentication)
  2. 🔄 Easy to Turn On/Off: You can enable or disable Redfish features without breaking other DMT functions
  3. 📦 Flexible Design: The Redfish module can be moved to its own project later if needed
  4. 🛡️ Clean Separation: Redfish code is kept separate from core DMT code to avoid conflicts

🎯 Clean Architecture Integration

flowchart RL

        subgraph DMT_SIDE["🏛️ DMT Console"]
            direction TB
            DMT_APP["🎯 Application"]
            DMT_CONTROLLER["🎯 Controller"]
            DMT_USECASE["💼 Use Case"]
            DMT_ENTITY["📦 Entity"]
            DMT_INFRA["🔧 Infrastructure"]
            DMT_APP --> DMT_CONTROLLER
            DMT_CONTROLLER --> DMT_USECASE
            DMT_USECASE --> DMT_ENTITY
            DMT_USECASE --> DMT_INFRA
        end

        subgraph RF_SIDE["🔌 Redfish Module"]
            direction TB
            RF_CONTROLLER["🎯 Controller"]
            RF_USECASE["💼 Use Case"]
            RF_ENTITY["📦 Entity"]
            RF_CONTROLLER --> RF_USECASE
            RF_USECASE --> RF_ENTITY
        end


    %% Module Registration & Shared Infrastructure
    DMT_SIDE -.->|"🔗 Module Registration<br/>🤝 Shared Infrastructure"| RF_SIDE
    RF_SIDE -.->|"📊 Device Queries<br/>🔄 AMT Device Access"| DMT_SIDE



    %% Styling
    classDef dmtLayer fill:#e3f2fd,stroke:#1976d2,stroke-width:2px
    classDef redfishLayer fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px
    classDef dmtContainer fill:transparent,stroke:#1976d2,stroke-width:3px
    classDef redfishContainer fill:transparent,stroke:#7b1fa2,stroke-width:3px
    classDef invisible fill:transparent,stroke:transparent

    class DMT_APP,DMT_CONTROLLER,DMT_USECASE,DMT_ENTITY,DMT_INFRA dmtLayer
    class RF_CONTROLLER,RF_USECASE,RF_ENTITY,RF_INFRA redfishLayer
    class DMT_SIDE dmtContainer
    class RF_SIDE redfishContainer
Loading

DMT Console (Shared Services)

  • Configuration Management: YAML-based configuration with environment variable overrides
  • Authentication & Authorization: JWT-based session management and RBAC
  • Logging Infrastructure: Structured logging with configurable levels
  • Database Abstraction: Repository pattern with transaction management
  • Middleware Pipeline: CORS, rate limiting, request validation, and monitoring

🔧 Enhanced DMT Console Capabilities

To support the modular architecture, the DMT Console will be enhanced with:

  • Redfish Endpoint Registration
  • Shared Services Injection
  • Module Lifecycle Management
    • Initialization: Load and configure Redfish module during startup
    • Registration: Register Redfish endpoints under /redfish/v1 namespace
    • Graceful Shutdown: Coordinated shutdown with core DMT services

📁 Redfish Module Structure

The Redfish implementation is organized as a self-contained module within the DMT Console repository, following Clean Architecture principles and Go module conventions

redfish/
├── openapi/
│   ├── dmtf              # Modified DMTF api specifications according to paths and components supported
│   ├── merged            # Merged DMTF api specification into a single file
│   └── infra             # Scripts, Makefile to support the openapi generation
├── internal/
│   ├── entity            # New entities added to support Redfish API
│   ├── usecase           # New usecases added to support Redfish API
│   └── controller        # Controllers implementing the Redfish endpoints under the `/redfish/v1` namespace
│       └── http/
│           └── v1/
│               ├── generated/    # Auto-generated code for the types and gin server interface of the Redfish APIs
│               ├── handler/      # Handlers implementing the Redfish resources
│               └── middleware/   # New middleware added to support Redfish API ex: HTTP basic auth
└── Existing Folders of DMT Console controller/use-cases/entities Plugin/middleware(logger, configuration, JWT authenticated, Database)

🔐 Security and Authentication Integration

The Redfish module leverages DMT's existing security infrastructure:

  • 🔒 TLS Encryption: Utilizes DMT's certificate management for secure communications
  • 📊 Audit Logging: Integrates with DMT's audit trail for compliance tracking

Detailed authentication and authorization are documented in Redfish Authorization and Authentication support in DMT.

⚡ Redfish OpenAPI Implementation Workflow

The Redfish controllers will leverage the OpenAPI specification for DMTF Redfish schemas as available in the DMTF GitHub repository here: Redfish OpenAPI Specification v2025.3. This GitHub repository is tagged with releases, and the latest one is 2025.3 released around October 21st, 2025. The openapi folder consists of multiple Redfish schema files, from DSP8010, in OpenAPI YAML format. The workflow that would be followed is described here:

flowchart TD
    subgraph DMTF["🌐 DMTF OpenAPI(GitHub)"]
        A["openapi.yaml<br/><small>Main specification</small>"]
        B["ServiceRoot.v1_19_0.yaml<br/><small>Service root schema</small>"]
        C["ComputerSystem.v1_26_0.yaml<br/><small>Systems schema</small>"]
        D["Chassis.v1_28_0.yaml<br/><small>Hardware chassis</small>"]
        E["Manager.v1_23_0.yaml<br/><small>Management controller</small>"]
        F["Other schemas<br/><small>Additional resources</small>"]

        A --- B --- C --- D --- E --- F
    end

    subgraph DMTF_REDUCED["🎯 DMTF Subset(DMT Github)"]
        A2["openapi.yaml<br/><small>Main specification</small>"]
        B2["ServiceRoot.v1_19_0.yaml<br/><small>Service root schema</small>"]
        C2["ComputerSystem.v1_26_0.yaml<br/><small>Systems schema</small>"]
        D2["Chassis.v1_28_0.yaml<br/><small>Hardware chassis</small>"]
        E2["Manager.v1_23_0.yaml<br/><small>Management controller</small>"]
        F2["Other schemas<br/><small>Additional resources</small>"]

        A2 --- B2 --- C2 --- D2 --- E2 --- F2
    end

    subgraph TOOLS["🛠️ Build Tools"]
        G["swagger-cli<br/><small>Normalize and Schema merging</small>"]
        H["oapi-codegen<br/><small>Go code generator</small>"]
    end

    subgraph DMT["🎯 DMT Implementation"]
        I["📋 DMT Redfish openapi.yaml<br/><small>Single merged spec</small>"]
        J["🔨 generated-server.go<br/><small>Auto-generated types & handlers</small>"]
        K["💼 Business Logic Implementation<br/><small>AMT integration & data transformation</small>"]
    end

    %% Connections
    DMTF -->|"Select & Reduce<br/>Schema Set"| DMTF_REDUCED
    DMTF_REDUCED -->|"Merge & Normalize<br/>Schemas"| G
    G -->|"Single Specification"| I
    I -->|"Generate Go Code - GIN"| H
    H -->|"Types & Handlers"| J
    J -->|"Implement Logic"| K

    %% Styling
    classDef dmtfStyle fill:#e3f2fd,stroke:#1976d2,stroke-width:2px
    classDef toolStyle fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px
    classDef dmtStyle fill:#e8f5e8,stroke:#388e3c,stroke-width:2px
    classDef outputStyle fill:#fff3e0,stroke:#f57c00,stroke-width:2px

    class A,B,C,D,E,F dmtfStyle
    class A2,B2,C2,D2,E2,F2 dmtfStyle
    class G,H toolStyle
    class I,J,K dmtStyle
Loading

Workflow Steps:

  1. 📥 Source: Start with DMTF Redfish OpenAPI specifications from GitHub. Pick and modify the schema files that will be used in DMT.
  2. 🔄 Merge: The schema files have names with versions embedded in them, for example: ServiceRoot_v1_19_0_ServiceRoot. Normalize the schema names by removing the version information. This will ensure that the types generated in the later step do not have version names embedded in them. Use swagger-cli to combine relevant schemas into a single specification after normalizing the version information.
  3. ⚡ Generate: Use oapi-codegen to create strongly-typed Go gin server code in the form of interfaces, data models, and handler stubs based on the merged OpenAPI specification.
  4. 🏗️ Implement: Implement the interfaces by adding the business logic for AMT device integration.

Technical Advantages

This code generation approach provides several critical architectural and operational benefits:

  • 🔄 DMTF Compliance & Version Control: Auto-generated types ensure 100% adherence to official DMTF Redfish specifications with direct schema version tracking and contract-first development
  • 📈 Development Efficiency: Eliminates ~70% of boilerplate code generation with strongly-typed Go interfaces that prevent runtime errors and enable automated refactoring
  • 🎯 Incremental Implementation: Enables modular schema adoption and progressive feature rollout based on AMT device capabilities without affecting existing DMT functionality
  • 🔍 Transparency & Gap Analysis: Provides clear API coverage mapping, AMT-to-Redfish translation documentation, and shareable OpenAPI specifications for stakeholder communication

🗺️ Redfish Resource Mapping

The following table provides a comprehensive overview of each Redfish resource type implemented within the DMT Console. Each resource type links to documentation covering implementation specifics and capabilities.

Resource Type Category Description
Systems Device-Specific Represents computer systems with ComputerSystem schema mapping from AMT data, including processor, memory, storage, network, power, thermal, and boot management capabilities
Chassis Device-Specific Provides physical hardware inventory including chassis information, thermal sensors, power supplies, fan control, physical security, asset tracking, and environmental monitoring
Managers Device-Specific Manages AMT controller capabilities including network services, certificate management, logging, virtual media, remote console access, and firmware update mechanisms
AccountService Service-Level Handles user account management within DMT context, including RBAC implementation, password policies, security settings, and account lifecycle management
SessionService Service-Level Manages authentication sessions, JWT token handling, session timeouts, cleanup procedures, and concurrent session limitations
EventService Service-Level Provides event handling capabilities including subscription management, filtering, routing, push notifications, and event history logging
UpdateService Service-Level Coordinates firmware updates across devices with scheduling, orchestration, progress tracking, status reporting, and rollback mechanisms

📊 Standards Compliance

For detailed information about DMTF standards compliance testing and validation results, see:

Console Wiki

ADRs

Clone this wiki locally