# Introduction to Redfish Interoperability Profiles François Donzé's profile photo François Donzé - Technical consultant, HPE July, 2024 Update: July, 2026 ## Introduction When I explain to an audience that the Redfish® standard requires the implementation of only a subset of the properties mentioned in the entire data model, I can see people looking at me puzzled and asking themselves: "*What? Are you telling me that there is a potential that some BMCs in my data center do not implement the `FirmwareVersion` property and yet they are considered to be compliant with the standard?*". The answer is yes. Those Redfish services that are not implementing properties not labeled "required" by the standard are still considered to be compliant. Although they are considered to be compliant, there are instances where this can be problematic. In this blog post, I'll elaborate and provide examples of use cases where it can be a problem. Then I'll introduce the Redfish Interoperability Profiles specification that has been created by the Distributed Management Task Force (DMTF) to address those use cases. The Redfish Interoperability Profiles specification constitutes another Redfish specificity that has been added to the list presented in part 1 and part 2 of the *Why is Redfish different from other REST APIs* blog posts. ### Redfish services can omit defined properties The DSP0266 standard document states in its Properties overview paragraph: * *Required properties shall always be returned in a response.* ![Figure 1: DMTF Properties overview paragraph from DSP0266](/assets/fig1-dmtfpropertiesoverview.6041803cdad8b125a15864c52434f6a0428fa30a26b685f62e3e2656db35cc5d.ee592370.png) Figure 1: DMTF Properties overview paragraph from DSP0266 This assertion suggests that some properties are not "required" in the implementation of the service. As an example, in the data model of the Baseboard Manager Controller (BMC) (Figure 2), the only required properties are: `@odata.id`, `@odata.type`, `Id` and `Name`. Since the `FirmwareVersion` property is not listed in this normative document, its implementation is not required in Redfish services. ![Manager required properties](/assets/fig2-managerrequiredproperties.d160edaa4442c721a93517863bc8a7c83d6b9b0ed27411b783a10bcacebcd75a.ee592370.png) Figure 2: Manager required properties Requiring the implementation of only a small number properties *provide[s] significant flexibility, and allow conforming implementations on a wide variety of products* as mentioned in the abstract of the standard document. ### Who cares? Flexibility is great, but too much flexibility can become an issue for standard organizations, software projects, or end users willing to move away from the Intelligent Platform Management Interface (IPMI) to Redfish for hardware management. Standards organizations and software projects, like the Open Compute Project® (OCP) and the OpenStack projects can only adopt Redfish as their preferred management protocol if they can easily define some sort of "baseline" containing which property must, should, or could be implemented in their managed nodes. Specific to OCP, the charter of the Hardware Management Project mentions: "*The hardware management specification incorporates [...] tools and best practices [...] for remote machine management*". This means that any server compliant to this specification must implement the network protocol(s) mentioned in the baseline. Systems supported by the OpenStack Ironic (bare metal machine provisioning) and the Valence projects (system lifecycle management) must implement a baseline of features containing at least the possibility to be powered on and off remotely as well. Redfish clients designed for managing multi-vendor systems also need a list of mandatory and recommended features. For example, if a system cannot return its BMC's firmware version, the client will have difficulties performing firmware updates. ## Redfish interoperability profiles To address the baseline issue mentioned above, the DMTF created the DSP0272 specification document that defines interoperability profiles. This document provides definitions, file naming conventions, examples and other information to help Redfish client developers to create their own interoperability profiles. Definition A Redfish interoperability profile (or profile) is a **JSON document** enumerating resources and properties that must, should, or could be implemented in a Redfish service. Properties mentioned in a profile are defined in a **JSON versioned schema file** part of the compressed (.zip) DSP8013 bundles. ### Didactic minimal profile example The following example is a minimal profile created for didactic purpose. It is not relevant for use in a proper production context. A summary of this example could be: *"To be compliant to this profile, Redfish services must model at least one manager (BMC) and must be able to return the manager's `FirmwareVersion` value"*. It is compliant with schema version 1.8.0 of the DSP8013-2024.1 bundle. This compliance is specified in the `SchemaDefinition` key below (first line). ```json { "SchemaDefinition": "RedfishInteroperabilityProfile.v1_8_0", "ProfileName": "FDZ's minimal profile", "ProfileVersion": "1.0.0", "Purpose": "This is a minimal educational Redfish interoperability profile.", "OwningEntity": "Koulapic", "ContributedBy": "FDZ", "License": "CC BY-SA", "ContactInfo": "fdz@koulapic.com", "Protocol": { "MinVersion": "1.6" }, "Resources": { "ManagerCollection": { "Purpose": "Redfish implementation must have at least one BMC.", "PropertyRequirements": { "Members": { "MinCount": 1 } } }, "Manager": { "Purpose": "Redfish implementation must ensure Manager is conformant to schema 1.5.1 or later and implements the `FirmwareVersion` property", "MinVersion": "1.5.1", "PropertyRequirements": { "FirmwareVersion": { "ReadRequirement": "Mandatory" } } } } } ``` Profiles contain administrative "self explanatory" keys like `ProfileName`, `ContactInfo`, or `Purpose`. The normative definition of those properties is in the schema mentioned in the above definition admonition. For this example I extracted in the next JSON block, the description of the `Protocol/MinVersion` property, which mentions that it is to be compared to the `ServiceRoot/RedfishVersion` of the evaluated Redfish service. ```json { "Protocol": { "type": "object", "description": "Requirements related to the Redfish protocol outside of the JSON resources.", "additionalProperties": false, "properties": { "MinVersion": { "$ref": "#/definitions/MinVersion", "description": "Indicates the minimum version of the Redfish Specification protocol support required by this profile. This version shall be reported by the Redfish service in the `ServiceRoot` resource property `RedfishVersion`. The version shall be represented using a `..` format, including an optional errata version. If this property is absent, the minimum value shall be `1.0.0`." } } } } ``` The `Resources{}` object of the above profile contains two members: `ManagerCollection{}` and `Manager{}`. The first one requires at least one BMC modeled in the evaluated Redfish service (`MinCount = 1`). The second requires the implementation of the `Manager/FirmwareVersion` (`ReadRequirement = Mandatory`). The other possible values for the `ReadRequirement` property are listed and described in the profile schema. I pasted them in the following JSON block. It is interesting to notice that, in addition to obvious values, like `Mandatory` or `Recommended`, others (i.e. `Conditional`, `IfImplemented`) need more attention. ```json { "ReadRequirement": { "type": "string", "description": "The read (HTTP GET) requirements for this property. The default value, or if `ReadRequirement` is not present, is `Mandatory`. For object properties, requirements of the embedded properties will apply only if the object is present.", "enum": [ "Mandatory", "Supported", "Recommended", "IfImplemented", "IfPopulated", "Conditional", "None" ], "enumDescriptions": { "Mandatory": "This property is required in all instances of this resource. For array properties, the property is required in all non-null array items. If `Values` is defined, at least one instance of each enumeration value is required among instances of this property.", "Supported": "This property is required to be supported by the service, but may not appear in all instances of this resource. The requirement is met if the property appears in at least one instance of this resource.", "Recommended": "It is recommended, but not required, that this property be supported.", "IfImplemented": "This property is required if the underlying functionality is implemented. For object properties, requirements on embedded properties within the object will only apply if the object is present.", "IfPopulated": "For property-level requirements, this property is required if the `State` property within the `Status` object for the object or resource does not contain `Absent`. This value is useful for properties within absent resources where empty slots, sockets, or bays are rendered with minimal properties until they are populated by a device. For resource-level requirements, this value indicates that the resource is required, but may not be present (populated) in the service at all times.", "Conditional": "This property is only required if `ConditionalRequirements` items apply to this instance of the resource.", "None": "This property is not required by this profile. It is listed here for clarity." } } } ``` ### Stacking profiles An interesting feature of Redfish Interoperability Profiles is that you can extend existing profiles with your own definitions at will. To create a profile that extends the Ironic profile, just use the `RequiredProfile{}` object as shown in the next example. This example specifies the URL and minimum version of the Ironic profile and yours. ```json "RequiredProfiles": { "Ironic": { "Repository": "https://github.com/openstack/ironic/tree/master/redfish-interop-profiles", "MinVersion": "1.0.0" }, "MyRequiredProfile": { "Repository": "https://koulapic.com/MyInteropProfiles", "MinVersion": "1.0.0" } } ``` Now that you understand the basic architecture of Redfish Interoperability Profiles, I encourage you to study the OCP and OpenStack public profiles. Don't forget to refer to the profile schemas in case you have problem understanding some properties, directives or objects. ## How to validate profiles? Profile conformance can be easily performed with the interoperability validator provided by the DMTF. It is a Python script that takes as input a configuration file and a profile. The main output is an HTML report. The following code block clones the validator GitHub repository and asks to create a configuration file and a profile. Then it launches the validator with those two files as input. ```shell git clone https://github.com/DMTF/Redfish-Interop-Validator.git cd Redfish-Interop-Validator # Create configuration file and profile python RedfishInteropValidator.py -c config/ilo-scott380g11-1.ini FdzMiniProfile.v1_0_0.json ``` The profile used in the above code example is the minimal profile mentioned [earlier](#didactic-minimal-profile-example). This profile requests at least one manager in the manager collection and a `FirmwareVersion` property in the `Manager` resource. To be sure the validator verifies those requirements, the configuration file (next code block) specifies `payload = tree /redfish/v1/Managers`. This line tells the validator to verify the profile directives at `/redfish/v1/Managers` and then follow recursively each and every link it finds and process them. The exact crawling algorithm is explained in the validator GitHub README.md file. ```shell # Profile Validator configuration file. # # Parameter description at: # https://github.com/DMTF/Redfish-Interop-Validator/blob/main/README.md [Tool] Version = 2 Copyright = Redfish DMTF (c) 2021 verbose = [Host] ip = https://ilo-scott380g11-1 username = username password = password description = iLO 6 forceauth = False authtype = Session token = [Validator] # The following `tree` keyword tells the Validator # to crawl the Redfish tree starting at the following # starting point. # # An alternative is `single` to only validate the # starting point. payload = tree /redfish/v1/Managers logdir = ./logs oemcheck = False online_profiles = False required_profiles_dir = debugging = False collectionlimit = ``` The validator outputs two files in the directory specified in the configuration file (`logdir`): a report in HTML format and a text file containing the different steps of the validation process. Figure 3 below is a portion of the validator report showing three successful verification. The first one (`Service level requirements`) requires the existence of the `ManagerCollection` and `Manager` end points. It has been automatically added by the validator as a mandatory condition before proceeding the verification of the other requirements mentioned in the profile. In the figure below, you can also view the results of the two verifications required in the profile. ![Figure 3: Redfish conformance test report](/assets/fig3-conformancetestreport.199282257cb92cda8eec4169856f35849cbab1161d8c729052e1bcb600edfc4c.ee592370.png) Figure 3: Redfish conformance test report ## Leveraging Redfish Interoperability Profiles Although present for a long time (January 2018) and despite an introduction video, the Redfish Interoperability Profiles specification is not very well known. It could be better leveraged by Redfish client programmers supervising heterogeneous data centers. As this standard, along with the interoperability validator, highlight the differences between Redfish implementations, it can help them produce a more efficient code quickly. If you already know a property is absent in a Redfish service, you can anticipate and adapt your code early in the development process. The OCP hardware management team is very active relatively to Redfish Interoperability Profiles. Several profiles are published in their GitHub repository that you can use "as-is" or extend as mentioned in the [Stacking profile](#stacking-profiles) paragraph. You can also help OCP further refine them by submitting ideas and feedback. With this blog post, I hope you discovered enough information about this Redfish standard to eventually use it or present it to friends or colleagues. And don't forget to check out some of my other blog posts on the HPE Developer portal to learn more about Redfish tips and tricks.