The DMTF has developed the following mockups so developers can interactively explore sample Redfish implementations (these mockups are provided for illustration purposes, and do not represent actual implementations). Click through and navigate the data model using the provided links, and select the info icons in the JSON payload to reveal definitions and other information about each property.
A typical 1U or 2U server intended for scale-out deployments.
This example represents an enclosure of "blade servers" that share infrastructure components, such as power supplies and fans. Depicting an enclosure containing four blade servers (a total of five "Chassis"), this mockup demonstrates the modeling of multiple chassis and systems managed from a single Redfish service.
A typical 1U or 2U server with local RAID Storage.
A managed SAS fabric with redundant switches.
This draft example, for ongoing development, represents a proposed minimal Redfish data model "profile" that meets the needs of the Open Compute Project’s Hardware Management requirements. This draft profile is intended to help define a list of required properties so that essential management-related tasks, as defined by OCP, can be performed on any Redfish implementation.
This example shows a service with various sets of disaggregated hardware as resources. It provides an example composed system utilizing some of the disaggregated hardware. It also shows how Resource Zones can provide information about binding restrictions.
This example shows how Redfish Composability can be used to create composed Computer System instances from smaller sets of Computer Systems. A top level enclosure called "Enclosure" contains a set of blades, which are used to create the composed Computer Systems.
This example shows a service with various sets of disaggregated hardware as resources. It provides an example two composed systems utilizing some of the disaggregated hardware. It also shows how Resource Zones can provide information about binding restrictions. It also shows how to express composition requests using the constrained composition format.
This example shows a service with various sets of disaggregated hardware as resources. The service itself provides information about the types of hardware available in the enclosure, but provides no composability functionality. In these circumstances, an external Redfish service might be used to orchestrate how the equipment is provisioned for composability.
This example shows a service that supports reporting telemetry data through the Telemetry Service. It has sample metric definitions and metric reports based upon data found in other portions of the data model.
Sample representation of DCIM equipment.
A lightweight Redfish service with OEM examples. The Service Root resource has been extended to have an OEM section. The service container also has an extension. The Account Service resource contains and OEM action. These OEM extensions are defined in the Contoso.com folder of the mockup.
Currently, PMEMConfig directory shows a mockup of initial configurations for reporting PMEM Devices and then the configurations after a sequence of configuration requests. The README describes each example and the files and directories related to that example.
This mockup contains a sample Redfish service for an NVMe-oF JBOF. The storage resources off of service root contain the provisionable storage for external hosts. The fabric portion of the data model is used to express host connectivity to the different NVMe namespaces. It also contains a single SoC, represented as a computer system, that is used as the front-end for receiving NVMe-oF traffic before the drives are accessed.