|
Post by jautor on Dec 7, 2017 17:36:48 GMT
Yes, the @redfish annotations can be used for any property, but we would recommend it be used very sparingly, and only to show where an implementation supports a subset of the enumerations (and typically only for properties that are read-write). We defined the annotation to allow client software to avoid "try and fail" semantics by showing what the supported / valid values were in advance. The "BootSourceOverride" is our best example of this, as you'd really like to know what is supported before trying it a dozen times until you find the one that works...
I'll take a look at the spec to see if we need to clarify that these payload annotations are used in that manner, and not just for Actions. Note also that we defined the "ActionInfo" resource to provide more information about parameter usage, and that may be a more appropriate solution in those cases.
Your OEM example is correct, but I would only show that data if that "LedColor" is a read-write property, or there's something else that a client would need to know what possible values it may see.
And as an aside with that example, which is fine to help replicate physical displays on GUIs, in Redfish we try to expose the underlying conditions instead of reflecting indicators. So assuming those LED colors have specific meaning (like fault, enabled, connected, etc.) the client is better served getting values that report those conditions. But as stated above, there's nothing wrong with providing this in addition to the underlying conditions, to help software reproduce the physical display 'look and feel'.
Jeff
|
|
|
Post by jautor on Nov 30, 2017 22:10:59 GMT
We discussed this today, and concluded that this would be useful information to add to the ActionInfo definition. We'll add "MinimumSupportedValue" and "MaximumSupportedValue" (exact name TBD) properties to the 'Parameters' object in the ActionInfo resource (schema). That work will be done as part of our 2018.1 release bundle. I'll update you with the final property names ASAP.
Jeff
|
|
|
Post by jautor on Nov 29, 2017 1:03:06 GMT
The SensorNumber property was included only to provide some mapping for early implementations to their legacy IPMI sensor information. For fans, there were several IPMI "sensors" typically related (the RPM measurement, the presence indication, and perhaps a fault signal), so the mapping is not obvious.
In my opinion, it would be better to provide meaningful values for Name, PhysicalContext and RelatedItems than to refer to the (legacy) IPMI sensor number.
However, if you have a use case that would show that information to be useful, it's certainly not a difficult addition to the Thermal schema. We would want to clearly indicate what sensor type (IPMI-defined) that the number would need to map to, in order to ensure interoperability.
|
|
|
Post by jautor on Nov 29, 2017 0:41:34 GMT
That does sound like a statement that was made in the specification before the concept of the custom/OEM role was added. I'll take this back to the group and get an opinion, but in my view you should be able to create a user with an assigned OEM role - not have to create and then modify it.
Jeff
|
|
|
Post by jautor on Nov 29, 2017 0:36:06 GMT
The AllowableValues array is only used for string enumerations. But your point is valid, and we should consider a mechanism for the service to expose its support for min/max values for integer types in parameters when it's not obvious. In my opinion, this is something that would be best suited in an ActionInfo resource for an Action.
Can you share an example of a parameter that this would apply to? We've generally tried to avoid integer values that have implementation-specific ranges (as opposed to well-known / static limits).
Jeff
|
|
|
Post by jautor on Oct 11, 2017 13:30:05 GMT
|
|
|
Post by jautor on Sept 27, 2017 20:42:27 GMT
Yes, the process of replacing a (default or otherwise) certificate is not currently defined in the Redfish schema. We're aware of that being a missing component and are working to add that topic to the model. If you have any suggestions or requirements on how this should work, please post them! We want to ensure that the general case of "upload a certificate" works for other use cases besides the needed TLS case...
Jeff
|
|
|
Post by jautor on Sept 27, 2017 20:35:08 GMT
What is the difference between "ForceRestart" and "PowerCycle" ? "ForceRestart" is described in ComputerSystem.v1_4_0.json as "The ForceOff value shall remove power from the system or perform an ACPI Power Button Override (commonly known as a 4-second hold of the Power Button). The ForceRestart value shall perform a ForceOff action followed by a On action." That sounds like a power cycle to me too, and not as the equivalent of pressing the physical reset button. Max, There's a subtle distinction, and one we probably should add to the descriptions to better explain - along with some guidance of which to use if there's no preference... We added the "PowerCycle" separate from "ForceRestart" because a restart does not require the power to be removed from a device. The reset could be accomplished by a hardware reset signal as opposed to cycling power. This may be exposing more of the implementation details than was necessary... This is a good question and one that I'll take back to the Forum. It would be good to clarify what happens for both of those values if the device is not powered on. Jeff
|
|
|
Post by jautor on Aug 31, 2017 23:18:06 GMT
Hi Mark,
Thanks for the feedback. Yes, we see that the lack of an OEM enumeration type in both of those fields is an issue. We discussed this issue and will add that support in the next release of the schema (which we publicly state is expected in 4Q17). To support the fact that there can be multiple OEM extensions, we'll also add two properties to LogEntry to report those when the SensorType or LogEntryCode value is "OEM".
We will have to have a discussion on the Sensor-specific types, but looking at those tables, my opinion is that it would be better for us to spend cycles on creating modern, Redfish-styled Events (which are used as LogEntry records of type "Event") that cover everything useful from those tables. Those would be standardized as additional message registries with defined messages, parameters, etc.
I'd appreciate your thoughts on that, too.
Regards,
Jeff
|
|
|
Post by jautor on Jun 7, 2017 5:20:06 GMT
rpajak, Just wanted to report that 'PowerCycle' was added to ResetType as part of the 2017.1 schema release. The updated schema files are available at www.dmtf.org/standards/redfish with the full bundle listed under "DSP8010". Thanks for the feedback, Jeff
|
|
|
Post by jautor on Feb 27, 2017 20:20:07 GMT
The JSON Schema file that defines the resource can be determined from the @odata.type returned in the payload.
The filename will be portion of the @odata.type after the hash and up to the last period. Example: for @odata.type of "#Chassis.v1_2_0.Chassis", the corresponding JSON schema file will be "Chassis.v1_2_0.json". Within the JSON schema file, the "title" will match the @data.type exactly.
Note that the JSON schema files may be accessible through the Redfish Service implementation - if there is a "JsonSchemas" collection, it can contain links to local or remote copies of the schema files.
They can also be accessed from the official DMTF Redfish Schema Repository at: redfish.dmtf.org/schemas Note that your schema-aware application should cache these files locally to avoid requirements for Internet access (and avoid latency and load on the server!).
Jeff
|
|
|
Post by jautor on Feb 26, 2017 23:19:07 GMT
Isn't it the same case with ManagerAccount schema? Yes, it is... We'll make a full pass through the existing schemas to correct any of them that are missing an Actions object. Jeff
|
|
|
Post by jautor on Feb 24, 2017 22:02:46 GMT
rpajak,
We'll take a look at this... I'll want to do some checking to see if we have a 'gap' in the coverage before we add more enumerations.
Jeff
|
|
|
Post by jautor on Feb 24, 2017 17:29:56 GMT
Max,
We can't easily mark these as "required" after release as part of the standard (because that wouldn't be a backwards-compatible change), but I understand and agree with your suggestion, and we'll take a look at least to add some strong recommendations - I think that will accomplish your goal.
Jeff
|
|
|
Post by jautor on Feb 17, 2017 22:40:28 GMT
Could you, please, clarify where the oem action should be added if there is no Action property in the DMTF resource schema - like Thermal resource. If there is an Action property in the resource, it is clear that oem action should be in Actions->Oem. But if there is no Action property in the resource there are following possibilities: We were supposed to define the "Actions" property in all (or at least most) of the Redfish schemas to allow for OEM's to add their own Actions, and keep them collected up in one, easily discovered location. Looks like we missed 'Thermal', I've marked that as a high priority bug, we'll revise the schema and get it released in the next bundle (which should come in March). So your #1 is correct. Jeff
|
|