Document Identifier: DSP2043
Date: 2019-12-06
Version: 2019.1
IMPORTANT: This document is not a standard. It does not necessarily reflect the views of the DMTF or its members. Because this document is a Work in Progress, this document may still change, perhaps profoundly and without notice. This document is available for public review and comment until superseded.
Provide any comments through the DMTF Feedback Portal: http://www.dmtf.org/standards/feedback
Document Class: Informative
Document Status: Published
Document Language: en-US
Copyright Notice
Copyright © 2015-2019 DMTF. All rights reserved.
DMTF is a not-for-profit association of industry members dedicated to promoting enterprise and systems management and interoperability. Members and non-members may reproduce DMTF specifications and documents, provided that correct attribution is given. As DMTF specifications may be revised from time to time, the particular version and release date should always be noted.
Implementation of certain elements of this standard or proposed standard may be subject to third party patent rights, including provisional patent rights (herein "patent rights"). DMTF makes no representations to users of the standard as to the existence of such rights, and is not responsible to recognize, disclose, or identify any or all such third party patent right, owners or claimants, nor for any incomplete or inaccurate identification or disclosure of such rights, owners or claimants. DMTF shall have no liability to any party, in any manner or circumstance, under any legal theory whatsoever, for failure to recognize, disclose, or identify any such third party patent rights, or for such party's reliance on the standard or incorporation thereof in its product, protocols or testing procedures. DMTF shall have no liability to any party implementing such standard, whether such implementation is foreseeable or not, nor to any patent owner or claimant, and shall have no liability or responsibility for costs or losses incurred if a standard is withdrawn or modified after publication, and shall be indemnified and held harmless by any party implementing the standard from any and all claims of infringement by a patent owner for such implementations.
For information about patents held by third-parties which have notified the DMTF that, in their opinion, such patent may relate to or impact implementations of DMTF standards, visit http://www.dmtf.org/about/policies/disclosures.php.
This document's normative language is English. Translation into other languages is permitted.
CONTENTS
The following files are part of the Redfish development effort:
This archive contains a number of mockups of various Redfish service implementations. They are intended to be a guide for learning about the Redfish Specification by showing typical examples of implementations. These mockups are not prototypes and do not reflect any actual product or Redfish implementation.
Many of these mockups are also used to populate the Redfish Resource Explorer, part of the Redfish Developer Hub located at: http://redfish.dmtf.org
This illustration of a Redfish service implementation shows a typical rack-mount server, as commonly used in scale-out data centers. It depicts the types of information that can be expected, but does not represent an actual implementation.
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.
This example shows a server with an implementation of the Redfish storage resources, showing an integrated RAID controller with four attached drives.
This example shows a more complex storage implementation using a pair of SAS switches, storage enclosures and multiple storage devices.
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 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 specific composition format.
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.
A mockup of initial configurations for reporting PMEM Devices and then the configurations after a sequence of configuration requests.