|
Post by jautor on Aug 14, 2018 19:16:25 GMT
At the beginning of each specification there's a section called "Terms and Definitions", which explains terms like "should" and "shall", as we use them to conform to the usage within ISO specifications.
In this case, yes, it's a recommended but optional part of the protocol.
Jeff
|
|
|
Post by jautor on Aug 14, 2018 19:13:23 GMT
|
|
|
Post by jautor on Jul 31, 2018 18:55:09 GMT
These values have generally been set by the manufacturer and have had service/warranty implications, and therefore were not settable by end users. However, there are certainly cases where they could be.
What are you expecting to do with a settable threshold? We have a Telemetry model currently available as a "work in progress" on the DMTF Redfish standards page that would allow you to generate events when defined thresholds are crossed, for example.
Jeff
|
|
|
Post by jautor on Jul 31, 2018 18:50:48 GMT
The use of the 'null' type should be restricted to cases where the information is not "currently available" due to startup/error/initialization - the value is truly unknown. Values not set by a client should be either omitted in the response (as is the case in the EventDestination example above), or in the case of PATCH-able, user-set properties, an empty string would be appropriate to allow the client to see the support of that property in the Service.
We're going to look at the wording in the spec as this is something that has come up a number of times and may need further clarification so we have consistent behavior...
Jeff
|
|
|
Post by jautor on Jul 31, 2018 18:46:20 GMT
In many "race conditions", the Etag concepts are there to resolve these issues. In the particular case you mentioned, no, there is no mechanism. Regardless of when the log was cleared, the second caller will eventually get 404 errors and will have to handle that.
Jeff
|
|
|
Post by jautor on Jul 31, 2018 18:40:21 GMT
The spec is silent on these request headers (hence, the "Service should understand ... as defined by the HTTP 1.1 specification..." statement). The handling of these is left to the implementation, and so should follow the semantics in the RFCs.
Jeff
|
|
|
Post by jautor on Jul 31, 2018 18:13:20 GMT
First, we'd like to see a proposal brought to the DMTF for this functionality as it would be a good addition to the standard schema functionality.
We could see this being performed as an Action (POST) to initiate the crash dump, which would likely create a Task. The Task monitor could return a URI (plus retrieval details) upon completion, using the TaskMonitorUri and a ReturnType (the CSDL definition to describe the response payload for that Action).
Jeff
|
|
|
Post by jautor on Jul 12, 2018 19:58:39 GMT
Hey jautor, I am still having issues understanding the IPv4AutoConfigEnabled property. The long description in the schema for this property is: "This property shall indicate whether IPv4 Stateless Address Auto-Configuration (SLAAC) is enabled for this interface." From my understanding, there is no such thing as IPv4 SLAAC. I see that you said it refers to IPv4 link-local addressing, but this is not the same thing as SLAAC. SLAAC is defined in RFC 4862 as an IPv6 protocol, with no mention of IPv4. I am not familiar with any other documents establishing a SLAAC protocol for IPv4. While SLAAC can configure link-local addresses, it also has the ability to configure routable global addresses. So, is there something we are missing (ie. IPv4 SLAAC) or is this an issue of an incorrect description? Thanks, Brad It's an incorrect description... And that will be addressed. The IPv4AutoConfigEnabled was intended to refer to the link-local autoconfig, but the description suffers from cut and paste syndrome... The object and property names will remain the same and we'll try to make the object-level description more 'generic' regarding auto-configuration. Jeff
|
|
|
Post by jautor on Jul 11, 2018 17:56:11 GMT
Not being familiar with that tool, I'm afraid we're going to need a lot more information to know whether this is a problem with our schemas or with the tool... We've seen a number of json schema tools that don't handle external references or 'definitions' correctly per the json schema spec, too. One issue I did find recently is that our schemas reference our extensions for the $schema, as in: redfish.dmtf.org/schemas/v1/redfish-schema.v1_1_0.json but the redfish-schema references itself instead of the json-schema, and if you hand-edit redfish-schema.v1_1_0.json with: "$schema": "http://json-schema.org/draft-04/schema#" you can see if that is the root issue for the pojo tool or not. We'll discuss this in the Redfish Forum and see if reaching out to the tool developer can perhaps get some insight - as those error messages aren't particularly helpful for diagnosing the issue without digging into the code... Jeff
|
|
|
Post by jautor on Jul 11, 2018 17:42:16 GMT
Hi, Could you have some guides that explain the usage of HttpPushUri? I'm in need of help on this to add support for softwareupdate via redfish on one of the embedded product. Thanks The HttpPushUri and the related 'target' properties are really the end of what is specified in Redfish. The actual implementation of a "push model" software update is not specified nor standardized. These properties were added to allow software to discover the existence of this type of support, but as there are many different, vendor-specific implementations, we did not attempt to define a new, standard, mechanism. Jeff
|
|
|
Post by jautor on Jul 9, 2018 20:53:19 GMT
Thanks Cactus, I'm looking into what happened to the file...
Jeff
|
|
|
Post by jautor on Jul 9, 2018 20:48:15 GMT
Hi Topher,
SLAAC is Stateless Address AutoConfiguration. The "IPv4AutoConfigEnabled" property refers to IPv4 link-local address autoconfiguration as specified in RFC3927. The ‘stateless’ part of SLAAC generally indicates ‘non-DHCP’, which does pertain here as well, although it’s certainly understandable that "SLAAC" does for many bring first to mind IPv6 and might be a possibly confusing reference here. The containing object probably should have been named something slightly more generic to avoid confusion with the IPv6 "SLAAC" terminology...
I'm going to open an issue on that schema to clarify the description for that property and perhaps the object as well, to explain this better.
Thanks for the question,
Jeff
|
|
|
Post by jautor on Jun 7, 2018 15:02:19 GMT
We could write a wrapper layer on top of UCS-M and expose Redfish interface, in this case, I was wondering how to implement configuration actions on the server like "Associate a blade server with a service profile template in UCSM". Redfish provides actions on resources like 'Reset' for Computer System but there are no examples of how to perform a configuration action on Computer System, for example, associate profile to the server. You would create OEM Actions in those resources to provide those functions. All of the Redfish resource definitions have both an "Oem" and "Actions" (with "Oem" defined within) objects where you can add your own extensions. There's an example of an OEM-defined Action on the Redfish Developer Hub here: redfish.dmtf.org/redfish/mockups/v1/863#Systems--437XR1138R2 "Actions": { "#ComputerSystem.Reset": { "target": "/redfish/v1/Systems/437XR1138R2/Actions/ComputerSystem.Reset", "ResetType@Redfish.AllowableValues": [ "On", "ForceOff", "GracefulShutdown", "GracefulRestart", "ForceRestart", "Nmi", "ForceOn", "PushPowerButton" ] }, "Oem": { "#Contoso.Reset": { "target": "/redfish/v1/Systems/437XR1138R2/Oem/Contoso/Actions/Contoso.Reset" } } }, Within the "Actions" object is an "Oem" object, with Actions named following the OEM extension pattern (OEM name . Action name). And I think your idea for providing this functionality for pre-Redfish systems a great idea! We're trying to identify any tools or functionality that can aid in the migration to Redfish, and these type of wrapper concepts are an area of interest. Hope that helps, Jeff
|
|
|
Post by jautor on Jun 5, 2018 18:37:13 GMT
We're working on some clarifications to explain the usage of these properties. We'll make those available as soon as they're approved...
Jeff
|
|
|
Post by jautor on Jun 5, 2018 18:20:17 GMT
By the way, if you work for a member of the DMTF Redfish Forum (working group), I'd suggest you contact your company representative to get clarification of all of this. But if not, we'll certainly help you work through the questions...
Jeff
|
|