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.
This example shows a set of managed power distribution units (PDU), including a rack-mount unit, a floor (row) PDU, and an automatic transfer switch.
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.
This example shows a server with an implementation of the Redfish advanced communication device (ACD) model using the NetworkAdapter, NetworkDeviceFunction, and Port resources.
This example shows a service with various composable elements. The composition service supports a Compose action, which allows a client to provide a manifest to perform a set of operations to allocate resources and compose systems. It also supports assignment of resource blocks into free and active pools.
This example shows an implementation that contains a set of cables and shows their connectivity to other components in the service.
This example shows an example power shelf with connections to an electrical bus.
This example shows a server with two SmartNICs installed. Each SmartNIC is modeled as a Chassis resource. The SmartNIC in slot 1 represents an SoC-based SmartNIC with its own system representation. The SmartNIC in slot 2 represents an FPGA-based SmartNIC. There is also an Ethernet fabric to show address pool configuration for the SmartNICs.
This illustration of a Redfish service implementation shows a fully featured tower server, as might be used in a rendering or development environment. It depicts the types of information that can be expected, but does not represent an actual implementation.