|
Post by jautor on Jun 8, 2023 19:08:12 GMT
The intent was for that to be "KVMIP" as the general "graphical console redirection", while "HostConsole" was expected to be text-based or terminal emulation modes (SSH/Telnet/Serial). And "WebGUI" was just that - any web-based GUI - which could include views of console(s) depending on the implementation...
If you have any suggestions for improving those descriptions, we'd take them!
Jeff
|
|
|
Post by jautor on May 31, 2023 2:52:23 GMT
The "Resolution" text was intended to be human-readable, and also can (and it is recommended) be replaced with more accurate or detailed text by the implementation.
If I understand the idea, if a client would be better able to dispatch some processes based on a set of standardized values, I think is something that we could add to the schema.
What would be in that list? Is it as simple as (one or more of): - Reboot / retry - Replace the faulty hardware - Upgrade the software / firmware - Contact the vendor for service - "OEM"
Essentially a gross-level "is this a hardware fault (dispatch a part), a software fault (reboot/reset, try again, upgrade fw), something we can't explain (contact vendor)" that can set some service processes in motion.
|
|
|
Post by jautor on May 26, 2023 19:55:15 GMT
Just an update that was added in Port v1.9 as part of the Redfish 2023.1 schema bundle that is now available: www.dmtf.org/sites/default/files/standards/documents/DSP8010_2023.1.zipAnd I'd like to call attention to the fact that the turnaround time from this request to a publicly available, approved standard was less than 90 days... The group places a priority on obvious, interoperable additions to the data model, especially in response to requests from end users. And as the DMTF Redfish Forum generally makes 3-4 releases of the Redfish schema bundle per year, that turnaround time is typical. And likely faster than a development/QA/release cycle for most product development teams (so, in general, you aren't "waiting on the standard"). Jeff
|
|
|
Post by jautor on May 26, 2023 19:35:29 GMT
Great! Two things...
#1 - I think we need to provide a "latest version" link for the DSP2043 ZIP bundle so you're not having to update the YAML every time we made a new release (and would like that to always grab the latest available). I'll request that and let you know what link to use in the future...
#2 - If you'd like, could you make a pull request on the Mockup Server README file to add this information and a link so folks can easily find it from that repo? We'll likely add some disclaimer text (since the DMTF won't be maintaining it), but I like making the shared work easy to find!
Thanks, Jeff
|
|
|
Post by jautor on May 24, 2023 1:56:30 GMT
Redfish Release 2023.1 Now Available
DMTF’s Redfish®, Release 2023.1 is now available for public download. Designed to deliver simple and secure management for hybrid IT and the Software Defined Data Center (SDDC), the latest release of the Redfish standard includes 28 schema updates and 11 new schemas as well as additional query parameters added to the syntax of the Redpath Specification.
The key highlights of the Redfish 2023.1 release are support for Cooling Distribution Units and CoolingLoops, including critical subsystems such as LeakDetectors, Pumps, Reservoirs, and Filters. Also included are enhancements to the Drive and Storage models with new DriveMetrics and StorageControllerMetrics resources and StorageController actions. Other additions include new standard message registries to define messages for common events or errors related to Platform, Power, and Environmental conditions.
These latest enhancements are driven by the growth of Redfish and interoperability feedback received from implementers. Some of the items in the new Redfish 2023.1 update include:
- Redfish Specification v1.18.0 – Adds URI segment annotation clause to allow schemas to describe URIs that do not match applicable naming rules.
- Redfish Specification v1.17.1 – Errata release. Improved M-SEARCH example response; updated authentication requirements to state that services can optionally reject requests to unauthenticated resources if the provided credentials are invalid; updated Action responses to provide guidance for finding the schema definition of the action response; and updated Response headers to make Access-Control-Allow-Origin an optional response header.
- Redpath Specification v1.1.0 – NEW - Additional query parameters added to the syntax
- 2023.1 Redfish Schema Bundle – This .zip file contains the current versions of all Redfish schemas. The bundle includes 40 schema updates and developer resources.
- NEW - Redfish for Cooling Distribution Units includes ThermalEquipment, CoolingUnit, CoolingLoop, CoolantConnector, Filter, Pump, Reservoir, LeakDetection, LeakDetector schemas
- NEW – Drive and Storage Controller Updates includes DriveMetrics and StorageControllerMetrics
- Added AttachNamespaces, DetachNamespaces, SecuritySend, and SecurityReceive actions to StorageController
- Added PartLocationContext to Location
- Redfish Message Registry Bundle 2023.1 – The Message Registry Bundle contains all released Redfish message registries.
- NEW Environment, Power, and Platform message registries
- Added TestMessage to ResourceEvent message registry
- Redfish for Thermal Equipment White Paper– This white paper describes the new Redfish data model support for thermal management equipment, including cooling distribution units (CDUs), heat exchangers, and immersion cooling units.
- Redfish Release 2023.1 Overview – This presentation provides detailed descriptions of each revision in Redfish 2023.1.
- Redfish Resource and Schema Guide – Updated for 2023.1 this human-readable guide to the Redfish Schema is designed to help educate users of Redfish. Application developers and DevOps personnel creating client-side software to communicate with a Redfish service, as well as other consumers of the standard, will benefit from the explanations in this resource. Includes example payloads for each resource type.
- Redfish Message Registry Guide – The Redfish Message Registry Guide presents message registry definitions in a more human-readable format and includes a summary table as well as individual message details.
- Redfish Property Guide – Intended primarily for schema authors, this newly revised reference helps with locating existing property definitions within the Redfish schema. Additionally, it helps avoid re-defining property names already in use.
- Redfish Data Model Specification – Includes normative statements (“LongDescription”) and informative description details from schema in a single document. Intended for both Redfish Service and client-side developers.
- Redfish Release History – Updated with each new release, this presentation offers a comprehensive view of each revision to Redfish since 2016.
- Redfish Conformance Testing Tools – Open source tools for service developers to validate their conformance with the Redfish protocol, data model, and profiles. Tools include the Redfish Protocol Validator, Redfish Service Validator, Redfish Interop Validator.
DMTF’s Redfish Forum would like to invite anyone interested in learning about the Redfish 2023.1 release to join a live webinar, hosted via Zoom, on Thursday, June 15, 2023, at 9:00 a.m. PT. The Forum chairs will present the contents of the release followed by a round table discussion. For questions regarding the webinar, email: webinars@dmtf.org. Don’t delay, be sure to register today!
To learn more about Redfish, click here. The Redfish Developer Hub is a one-stop, in-depth technical resource and provides all the files, tools, community support, tutorials and other advanced education you may need to help you use Redfish. Technical work on the Redfish standard takes place in DMTF’s Redfish Forum. To find out how you can join and contribute to this standard, click here. To submit input via the DMTF Technology Submission and Feedback Portal click here.
|
|
|
Post by jautor on May 23, 2023 20:29:18 GMT
|
|
|
Post by jautor on May 23, 2023 20:24:33 GMT
Hi Neil,
I was looking through some of our published materials, especially in the DCIM space (power and cooling gear), to see if there was something good to point to. But I'm not finding much that fully explains (or excuses!) the model...
So you're absolutely correct that resources in the data model generally fall into either the "physical" or the "logical" category - but I have suggested that we use the term "functional" instead of "logical" - because that term is so heavily overloaded in the IT / OS world. And what you also need to understand is that in the Redfish data model, there's going to be a mix of good answers, bad answers (which hopefully are deprecated in the model, but kept in place for backward compatibility), and items that may seem to be duplicate answers - but are intended for different types of gear. And all of that may not be obvious, and certainly not without reading the schema guide-level descriptions and details. And even then, I'm sure there's room for improvement in many places - where it was clear to the authors because we're super close to it - but won't be at all obvious to anyone else... Any feedback to improve any of that is welcomed and encouraged!
And so I think we need to add some guidance and history, probably to the "Redfish Data Model Specification" so it's in a place that folks will find it, regarding the physical/functional views in the data model. But let me give a start of that...
We modeled the physical view mostly through the `Chassis` resource. Where a Chassis is roughly a sheet metal box. And our recent guidance has been that every physical thing must be "Contained" by a Chassis. That can be assumed for resources subordinate to a Chassis resource, or can be called out by a Link called `ContainedBy` that points to the physical Chassis. For things bigger than a rack, such as a room or a building, we made the `Facility` resource. And we jokingly say that's just a Chassis made out of drywall or concrete instead of sheet metal...
Everything else in the model is a "Functional" resource - which in the general-purpose computer /server space means any resources visible from the operating system. Now, you'll see items like Processor and Memory which represent both - and we did that to avoid a lot of duplicate resources (one for the physical DIMM, another for the 128GB of RAM it surfaces to the OS). And that same resource can also represent an empty slot (an Absent resource in our terminology) so we don't have to model that as yet another resource.
And so in those functional resources, you'll see links to a Chassis to show that physical containment. Or again, it can be assumed for subordinate resources (there's a Chassis link for Memory, but not in MemoryMetrics, for example). And in Chassis, you'll see links to all the potential functions that could exist (and be contained within). And while that list of links continues to grow - we wanted to give explicit links for each schema type - so that a client didn't have to chase down every resource just to determine which ones were relevant.
Over time, we've tried to make this more consistent, as folks have also become more comfortable with a few additional "overhead" resources (a simple Chassis that contains one function like a PDU) in exchange for a very consistent model to determine physical containment, location, etc.
So that's a start, I've brought up the topic and I'll be proposing some text like the above to add to the educational materials. Because it's important for both implementers and users to understand how the model is supposed to work!
Jeff
|
|
|
Post by jautor on May 9, 2023 20:08:31 GMT
Yes, thanks - this was already reported and has been fixed in the next release of the registry.
Thanks, Jeff
|
|
|
Post by jautor on May 5, 2023 2:57:30 GMT
So actually like the item1, we also shall response PropertyNotWritable message instead of NoOperation. Yes, I agree, and I think we need to clarify that "exception" in the specification because the PropertyNotWritable response makes much more sense for any link/reference property (whether it is defined in schema as read-only or implemented as read-only). Jeff
|
|
|
Post by jautor on Apr 27, 2023 18:11:15 GMT
Note that you can also create your OEM schemas in CSDL (XML) format and use the DMTF-provided open source tools on GitHub to convert the CSDL to JSON schema and OpenAPI YAML files - which gets you all three supported schema formats...
But yes, an OEM JSON schema file should contain those properties as defined so that any client or tools that attempt to operate on Redfish schemas will also function with your OEM schemas.
Using the "redfish-schema-v1.json" $schema reference is preferred as we update that "v1" file to match the latest, backwards-compatible version of the file. And the "title" should follow the format shown in the specification, which you show in your example as "#OEMJsonSchema.v1_0_0.OEMJsonSchema"
Jeff
|
|
|
Post by jautor on Apr 17, 2023 0:47:41 GMT
Yes, you must support that to avoid interoperability issues... Without that support, a client would be required to GET the resource to discover the number of array elements, in order to PATCH to replace the entire array. In other words, with the exception of the empty object or a null element, the entire array is replaced with the value in the PATCH. It's those exceptions that allow short cuts to make it easier to modify an array from a simple script or by a manually crafted command.
Your Scenario 2 has those elements in the wrong order (should be ["ComputeBlock0", null, null]), but yes, both of those must work and would produce the same results. In addition, the easiest way for a client to perform this would be a PATCH with a single empty object to "preserve" the existing value:
"ResourceBlocks": [ {} ]
or even "ResourceBlocks": [ {}, null, null]
Jeff
|
|
|
Post by jautor on Apr 11, 2023 19:12:34 GMT
Glad you figured it out. I think we may want to re-order or otherwise enhance the tool as it attempts to identify simple errors in property names. It seems like it found the "FirmwareVersion" in the listed version of schema vs "AdditionalFirmwareVersion" defined in a later version. The tool should probably check later versions for exact matches (the more likely error case) prior to doing the fuzzy searches for typos.
Jeff
|
|
|
Post by jautor on Apr 7, 2023 16:17:31 GMT
The PropertyNotWritable message is intended for reporting properties that are defined as read-write in schema have been implemented as read-only. And that message is really only needed if the operation fails, or if the service needs to explain that while an operation suceeded, it didn't incorporate one or more properties.
But PUT usage is not common for public-facing clients (and not required by the specification). I would expect that any PUT support is likely from an internal-side data provider which doesn't adhere to the RO/RW definitions anyway.
The specification also allows the service to simply ignore/discard RO properties provided in a data modification request. That is to allow for a read-modify-write of a Redfish resource without requiring the client to remove data from a previously gathered/stored response payload.
Jeff
|
|
|
Post by jautor on Apr 6, 2023 13:52:48 GMT
So it is flagging that as an error, with the messages at the bottom of the report in your image - the "ERROR - CollectionFunction is not defined". But it is not showing that error in-line for the property itself. This may be due to array property handling (which has a different code path), or, it may be a result of the tool actually matching the "CollectionFunction" to the correct "SupportedCollectionFunctions" name. The tool attempts to test against simple typographical errors in property names to do as much testing as possible. But it will still report those as errors. Could you try renaming "CollectionFunction" to something very different, like "FluffyBunny" and see what the report shows? Either way, please open an issue on GitHub for the tool, as while it is properly detecting the error, I agree that should be reported in the table and not just as a message at the bottom of the report. github.com/DMTF/Redfish-Service-ValidatorThanks, Jeff
|
|
|
Post by jautor on Mar 24, 2023 14:36:47 GMT
And that's certainly not helpful or the intent of the property. We want you to be able to determine which credentials to use on a "discovered" Redfish service. So the combination of 'Vendor', `Product`, and the recently-added `ServiceIdentification` property should tell you #1 what category/product am I talking to, and #2 which instance (in the likely case where there are multiple, otherwise identical devices) you've found.
That information can then be used to match up pre-shared credentials, via whatever process exists from the vendor to deliver those credentials.
But if those properties don't provide enough differentiation, that process breaks down...
Jeff
|
|