|
Post by jautor on Jun 5, 2018 15:59:21 GMT
Francine,
And if you've identified something that would be useful for other implementations, please propose it as something we could add to the standard - we can add enumerations to the list (we do it all the time for additional use cases).
Jeff
|
|
|
Post by jautor on May 22, 2018 22:42:57 GMT
Hi Tom,
We discussed this with the group, and think this is a good addition to Placement, as we don't have an "unstructured, in-the-room location" for gear that doesn't fit in the row/rack datacenter naming.
We'd like to find a more generic term than "(Floor) Tile" for this purpose, as we'd like to use a single property to hold this in-the-room location. Some folks will use floor tiles, while other may use posts or an X-Y system for in-room locations.
My thought would be to name this property using another synonym of location: area, position, spot or point.
My preference would be "Area" given the choices I was able to come up with...
Any suggestions anyone?
Jeff
|
|
|
Post by jautor on Apr 26, 2018 3:49:45 GMT
Are empty strings common in Redfish payloads? I don't see anything in the specification that prohibits empty strings for things like "Manufacturer" and "Name", though maybe "null" is a better value in those cases. Very specifically, should our UI give the user the ability to "blank" a text field and send an empty string? I am trying to think of good examples where that would be needed. Thanks for the assist! We're trying to get consistent behavior for "undefined" or "unavailable" strings, and I've suggested to the group that we add a schema annotation indicating that an empty string is acceptable or not. We should only expect to see empty "" strings in cases where the data is user-defined or otherwise settable with no default value. If the data is not available for other reasons (errors, uninitialized data, etc.) then null is the correct response. What we certainly don't want, though, is for implementations to invent data or fill in placeholder (DON'T use "N/A", "[not set]", etc.). "Name" and "Manufacturer" are both properties that should have text available unless an error has occurred (and they are read-only). An example of one that could be an empty (blank) string is "AssetTag". But your point about a user setting a blank string is a good example for us to add to the spec - that is valid data and should be accepted and returned as such - it should not be translated into null. Jeff
|
|
|
Post by jautor on Mar 16, 2018 15:38:38 GMT
Is there an example of how Oem Actions would be defined in an Oem extension and how such actions would be referenced in the Actions.Oem section of the resource instance. In the mockup for rack server ComputerSystem, I see an action Contoso.Reset but it is unclear how client would know which schema to reference. Just wondering if there is missing information in the mock? Thanks Yes, you've found a small hole in the spec, which I'll work with the group to close. The answer will be to use the schema defined in the "Oem" section which should contain any definitions for OEM Action(s). We originally had placed the OEM Actions in the "Oem" section, but moved them under Actions in the final v1.0 spec so that software looking for Actions would be able to find them. But that move lost the linkage to the OEM schema. So if you have no OEM properties to extend in that schema, just create an "Oem" section with nothing except an "@odata.type" to refer to your OEM schema (which has the OEM Action defined). I'll recommend that the group add language to the spec to make that linkage... And update the mockups to show examples of that. Thanks! Jeff
|
|
|
Post by jautor on Mar 14, 2018 21:35:46 GMT
1. Any body know what those parameters of simple update action are used for? Please give some examples of parameter ImageURI and Target. 2. What the fw action flow when user give a POST to /redfish/v1/UpdateService/Action/SimpleUpdate Thanks a lot There are three parameters defined for the SimpleUpdate Action. Looking at the latest JSON Schemas, I'm not seeing them documented (they are in the CSDL XML, however), so that needs to be investigated and corrected. But they are defined as: TransferProtocol | The network protocol used by the Update Service to retrieve the software image file located at the URI provided in ImageURI, if the URI does not contain a scheme.
| ImageURI | The URI of the software image to be installed. | Targets | The array of URIs indicating where the update image is to be applied.
|
ImageURI is the critical parameter here. Many implementations will apply the image to the relevant device(s) without specifying (or even supporting) the "Targets" parameter. The firmware flow upon receipt of a POST here will depend a lot on the implementation and what is being updated. Jeff
|
|
|
Post by jautor on Mar 7, 2018 17:21:08 GMT
Sorry for the noob question. Our product has a number of USB ports. We are wondering where (or if) we should show a collection of USB ports. Should it be an OEM? Or should we use the generic Switch/Port schemas? In the short term, an OEM section would be the best option. We certainly don't think you should attempt to model those with the Switch/Port schemas - that would be overkill. But we are curious as to what you are trying to model here for those USB ports? Are you just trying to show their existence, want to use them as a target for a "RelatedItem" link in a device resource, or want to show the attached USB devices? And we'd encourage you to bring a proposal to the SPMF if there's interest in adding support to the standard... Jeff
|
|
|
Post by jautor on Mar 7, 2018 17:17:19 GMT
Hi Joergweek, Yes, as SPMF looked at that section due to that other post, it was obvious that the specification needed clarification. That is correct, if any properties were updated, return 200. Any properties not updated should provide Message objects within ExtendedInfo. Yes, the response is the same regardless of why some properties were not updated. It was not our intention to restrict this behavior to attempts to update read-only properties, but the specification language does seem to imply that. We're going to fix that by re-wording those points and providing examples for these cases (including the "all" case below). Would not be 405, but 400 (bad request). We will clarify this section as well. When it comes to allowing "partial success" PATCH requests, the Service should do whatever makes sense (or within reason) for the implementation. We do not want the Service to allow resources to get into invalid configurations or other problems by forcing partial updates to always process. So if it makes sense for the resource (or just for code simplicity), it's allowable for the Service to reject the entire PATCH request if some of the property updates requested are invalid. I expect we will have these clarifications completed for the next revision of the Redfish Specification. Thanks, Jeff
|
|
|
Post by jautor on Feb 14, 2018 18:28:49 GMT
Hi, Questions related to chapter 7.8.2. “Schema variations”.
Assuming we have a service that uses the standard Redfish schemas, e.g. for ComputerSystem. Schema is not modified according to 7.5.2.1 “Schema Modification Rules”. But the Redfish service still supports only a sub-set of the properties in the ComputerSystem schema.
In this scenario I would assume that a client should only be allowed to PATCH the ComputerSystem properties that the Service actually includes in the response body at GET on the same resource. But I cant find such statement in the specification. The specification states that PATCH of resource properties that are e.g. ReadOnly in the service should be possible (but as they will not be updated the error message should be provided). But this section does not state anything about handling of resources that are not supported at all by the service, such as standard Redfish schema resources not supported by the service.
But when I read chapter 7.8.2 (bullet 1) it looks like the service shall support a PATCH of “unsupported” Standard Redfish property via Settings data / resource: “All Redfish Services must support attempts to set unsupported configuration elements in the Setting Data by marking them as exceptions in the Setting Data Apply status structure, but not failing the entire configuration operation.”
Hi fish, Looking at that section in the specification, it isn't clearly worded and needs some work. We need to move this information out of the "schema" section, as it is not about creating the schema, but about the operations on a resource. In general, you would not expect to support a PATCH to a property that is not supported by the implementation. For example, if your implementation doesn't support the "AssetTag" property, you don't have to allow a user to create one via PATCH, either. But there are cases in the Redfish model where properties will come or go depending on the "type" of a particular resource instance or upon a change to its configuration. For example, a NetworkDeviceFunction may be configured (via "NetDevFuncType") to appear as a "FibreChannel" device. But a PATCH to change that instance to appear as a logical "Ethernet" device would cause a number of Ethernet-related properties to appear, and any FibreChannel-related properties to be removed. That implementation would certainly want to allow a single PATCH operation to both select the new "NetDevFuncType"="Ethernet" and configure all the Ethernet-related properties (that don't appear in the resource when it was configured to be a "FibreChannel" instance). We do need to add some text here to clarify that the PATCH behavior is the same for unsupported properties as it is for read-only properties. And we need to clarify how that is handled for a single PATCH, or a multiple PATCH operation, as well as within the Settings object. Yes, it's because there are cases where those Settings may cause new properties to appear, or others to be removed. This section needs clarification as well. I've opened issues against the Specification to get these areas improved... Thanks! Jeff
|
|
|
Post by jautor on Feb 2, 2018 18:53:28 GMT
Hi, A Redfish service needs to respond with some temporary string data in the HTTP response body of an OEM action. This string data is not naturally a property of any resource. But I conclude from the specification (1.4) in chapter 6.4.4.7 “Actions (POST)” that response body of Action (POST) must only include data in the form of a message /error-message. And I want the action the be Redfish compliant still. Does this mean I need to find some work-around like exposing this data as some kind of temporarily available resource property, or exposing some property with an URI for downloading this string data as a separate file (“outside” Redfish API), after the action has been invoked?
Is there really no data in the resource that relates to the Action? Is that string data something that would be appropriate for a "Message" response? But this topic has come up once before, and I'll bring it up again to see if this is something that the Forum sees as something to address in the specification. If you can provide any examples (even hypothetical) of cases where this pattern would get used, that would be helpful to make the case. Thanks, Jeff
|
|
|
Post by jautor on Feb 2, 2018 18:48:29 GMT
Related observation: same chapter 6.4.4.7 “Actions (POST)” says: “In cases where the processing of the Action may require extra time to get completed, the service may respond with an HTTP Status code of 202 with a location header in the response set to the URI of a Task resource.”
I guess this is wrong? Should be “Task monitor” and not “task resource”? According to chapter “8.2. Asynchronous operations”: “Any response with a status code of 202 (Accepted) shall include a location header containing the URL of the Task Monitor and …”
You are correct, that is an errata in a number of instances in that section, and needs to be corrected. We will fix that in the next release of the Specification. Thanks for finding and reporting that! Jeff
|
|
|
Post by jautor on Jan 5, 2018 15:46:26 GMT
Yeah, that's a bug - thanks for pointing that out. The "@odata.etag" property is called out in the specification, and will validate against our schemas because of the "@odata" pattern match, but we do call out the other defined (and in most cases, required) @odata properties in each JSON schema. I'll open an issue with the group to get it added in the next release.
Jeff
|
|
|
Post by jautor on Jan 5, 2018 15:27:19 GMT
My first suggestion is that if you've got a large list of resources to 'reference', that you probably want to see if that's really the proper model for the topic. But yes, large arrays of links are not optimal - you may want to create separate collections for those things.
Look at your software (client) use cases - how will a typical client want to use this data? If you have a large collection that isn't normally consumed as a whole (and only as a filtered set), it may be better to break them into separate collections. And the 'rare' software that wants to see "all those thingys" can do the extra bit of work to gather up the separate collections.
Jeff
|
|
|
Post by jautor on Jan 1, 2018 21:26:10 GMT
|
|
|
Post by jautor on Dec 15, 2017 20:23:35 GMT
But I am still wondering how to represent the Drive Slot resource which has some properties such as status(OK/Warning/Critical) and state(Enabled/Disabled) with the Redfish Schema Should I use Chassis(Component or Other) to represent the drive slot, so the JOBD device can be represented as: Chassis(RackMount) - Chassis(Component/Other) - Drives
You would model the drive slot and the drive together. An empty drive slot would appear as a member of the Drive collection with an "Absent" state (in Status), and very few other properties. The slot number and related details can be shown in the Location object (for a drive and for the slot). Is there some other status/state that you'd need to report separately? We don't want to represent the LEDs themselves, but rather the information that they convey. The "IndicatorLED" property is shown as that is the function - to provide a visual identifier to a user (location / identifier). Other LEDs that show the status of a drive or it's power on/off - should be conveyed through the Status object properties. This allows software to obtain the underlying information with better detail than is typically made available (and not in a consistent manner!) with simple LED on/off/blinking information. Jeff
|
|
|
Post by jautor on Dec 7, 2017 17:52:09 GMT
In 2017.2 schemas the RoleId property was added to Role resource.
This proerty is also annotated with requiredOnCreate, meaning that client will have to provide value at create (POST till role collection).
To me this looks like a none backward compatible change, beacuse clients that are not updated to the new schema yet will not provide the new property RoleId, and updated servers will reject POST/create without this property. In short: this will break in case of old client towards new server. Also I think that annotation "requiredOnCreate" is fairly new, so older clients (or not so advanced clients) would not understand this anyway.
Do you agree that this is actually not backward compatible? Or am I misunderstanding something here? Or how can I avoid backward compatibility issues here? (Scenario is to lift server implementation from older schemas to newest schemas.)
It is technically backward compatible because both the client and the service can use the schema version to indicate their support. But yes, this is a case where some care will need to be taken in implementation, and while it's not perfect, we are trying to minimize disruption to clients and services as much as possible - which means making fixes to ensure interoperability as we find them. That was the case here, as RoleId needs to be provided to create an account - as any "default" behavior may have negative implications. To allow this to work, a client should only POST to create an account using the schema version that the service supports, but normally, the Service should just ignore and discard unknown properties. Service can return a message showing what was discarded, and may choose to fail the request, too. Jeff
|
|