[RFD]: Redfish Interface Strategy

[ManuelSopenaBallesteros]

Decision Goal

• Create a process in which vendors and OpenCHAMI community could integrate vendor's Redfish implementation in OpenCHAMI.
• OpenCHAMI to support multiple vendor-specific Redfish implementations.
• Integration OpenCHAMI with different Redfish implementations from different vendors and different versions.
• Sites deploying OpenCHAMI must be able to easily configure support for their hardware.
• The solution must remain accessible to small sites with limited engineering resources.

Category

Other

Stakeholders / Affected Areas

users, vendors, developers

Decision Needed By

No response

Problem Statement

1. Overview

This document proposes an approach for integrating multiple Redfish implementations into Ochami, enabling support for heterogeneous hardware environments while maintaining usability for small sysadmin teams.

2. Problem Statement

The Redfish specification defines a standard interface for hardware management, but in practice:

• Vendors implement Redfish inconsistently.
• Hardware-specific quirks require custom handling.
• Compatibility cannot be assumed across vendors such as Hewlett Packard Enterprise, Dell Technologies, or Supermicro.

Redfish integration is a critical aspect of modern system management. It provides the primary interface to hardware systems, enabling essential capabilities such as hardware inventory, power management, boot configuration, and remote console access.

However, the Redfish specification allows for significant flexibility, resulting in variations across vendor implementations. This lack of strict standardization introduces challenges when developing portable and reliable Redfish clients.

For OpenCHAMI, leveraging Redfish is necessary to achieve feature completeness. At the same time, it must operate across diverse environments where the Redfish implementation, version, and vendor-specific extensions cannot be assumed in advance. This variability increases integration complexity and makes it difficult to design a one-size-fits-all solution.

Additionally, developing and maintaining Redfish clients can be resource-intensive—particularly for smaller sites with limited engineering capacity.

This Request for Discussion (RFD) aims to initiate a broader conversation around improving the strategy and defining clear guidelines for integrating Redfish into OpenCHAMI. The goal is to reduce complexity, promote reuse, and establish a more consistent and maintainable approach across components (DMS, PCS, magellan).

3. Goals

• Enable Ochami to interact with diverse Redfish implementations.
• Minimize operational complexity for end users.
• Allow vendors and the community to contribute support.
• Provide a scalable mechanism for adding new hardware support.

4. Proposed Solutions

4.1 Option A: “Battery-Included” Approach

Ochami includes all supported Redfish client implementations directly in its source code.

Description

• All Redfish implementations are bundled into the Ochami codebase.
• Official builds include a predefined set of supported hardware.
• Documentation lists compatible systems.
• Vendors may distribute their own Ochami builds with additional support.

Advantages

• High integration and simplicity for end users.
• Single binary deployment.
• No runtime plugin management.

Disadvantages

• Reduced flexibility.
• Larger codebase and binaries.
• Community may lack access to vendor hardware for testing.
• Sites with mixed hardware may need to build custom binaries.
• Requires a build system capable of selecting specific Redfish clients (e.g., via a configuration file).

---

4.2 Option B: Plugin-Based Redfish Clients

Ochami loads Redfish client implementations dynamically via plugins.

Description

• Ochami provides a core binary.
• Redfish clients are distributed as separate libraries (plugins).
• Users install plugins by placing them in a designated directory.
• Each plugin implements a defined Ochami Redfish interface.

Advantages

• High flexibility.
• Independent release cycles for plugins.
• Vendors can distribute and maintain their own plugins.
• Smaller core binary.

Disadvantages

• Requires version compatibility management.
• Increased responsibility on plugin developers for quality and documentation.
• Potential risk to Ochami’s reputation if plugins are poorly implemented.

---

5. Compatibility and Validation

To support the plugin model, Ochami must provide:

• A plugin compatibility mechanism, including:

  • Version matching between Ochami and plugins.
  • A compatibility matrix (maintained by vendors or community).

• A validation http API, allowing:

  • Listing available Redfish clients.
  • Verifying plugin compatibility at runtime.
  • Detecting invalid or incompatible plugins.

---

6. Redfish Client Selection Mechanism

A key challenge is determining which Redfish client to use for a given system.

Proposed Approach

When Ochami connects to a Redfish endpoint:

1. It performs a discovery request to the Redfish service root (/redfish/v1).

2. It inspects standard Redfish resources such as:

   • /redfish/v1/Systems
   • /redfish/v1/Managers

3. It extracts identifying metadata, including:

   • Vendor (Manufacturer)?
   • Model (Model)?
   • Firmware version?
   • Redfish version (RedfishVersion)?

Client Selection Strategy

• Ochami evaluates the discovered metadata.

• It matches the system against available Redfish clients using:

  • Vendor?
  • Model?
  • Optional firmware/version constraints?

• The selection can be implemented as:

  • Rule-based matching (e.g., plugin declares supported devices)
  • Priority-based fallback system

---

7. Implementation Details

• Ochami defines a Redfish client interface that plugins must implement.

• Plugins declare:

  • Supported vendors/models
  • Compatible Ochami versions

• Ochami provides:

  • A discovery mechanism
  • A plugin registry
  • A validation API

---

8. Recommendation

The plugin-based approach is recommended because:

• It scales better with ecosystem growth.
• It allows vendors to maintain their own integrations.
• It avoids bloating the core Ochami binary.

To mitigate its drawbacks:

• Provide strong interface definitions.
• Enforce compatibility checks.
• Offer a small set of officially supported plugins for common hardware.

---

9. Open Questions

• Define responsabilities about creating redfish clients?
• Define a process for vendors to introduce/integrate their redfish clients to the openchami project/documentation
• What level of testing/validation is required for “official” plugins?
• Should there be a fallback generic Redfish client?

Proposed Solution

No response

Alternatives Considered

No response

Other Considerations

No response

Related Docs / PRs

No response