sag
Minnow
Posts: 14
|
Post by sag on Sept 4, 2019 15:27:55 GMT
Suppose we take a Chassis resource:
{
"@odata.id": "/redfish/v1/Chassis/Blade1",
"@odata.type": "#Chassis.v1_5_0.Chassis",
"Id": "1",
"ChassisType": "Module",
"Location": {
"Location" refers to abstract Resource.Location.
What determines which version of Location (Resource.vXYZ.Location) is allowed
to show up here?
Can a client determine which properties can appear in "Location" just by looking at this this single URL?
There are similar properties to which this question pertains, like "IPv4Adresses" in EthernetInterface.
|
|
|
|
Post by jautor on Sept 6, 2019 19:40:06 GMT
The references to those "un-versioned" resources are used sparingly, but where they are used, they don't contain a specific version because that would tie them together and force a lot of unnecessary revisions of both schema and implementations. So the short answer is - no, you can't tell.
But the longer answer is that in most cases where these references occur - you can tell based on usage, and if not, it's backward compatible and unlikely to impact your implementation.
In the case of `Location`, any supported property (which are mostly user defined/settable strings) would exist in the Location object, and if not set, have an empty string value.
In cases where the reference is to an enumeration type (e.g. `ResetType`), the @redfish.AllowableValues annotation would describe the values the implementation supports.
The cases left over are objects like `IPv4Addresses` where some properties were added over time, and in that case, if the property doesn't appear, it's not likely supported, and any blind PATCH attempt may fail. But we believe this is a very small corner case - and we've been willing to accept that additional client complexity over the version ties that would cause a lot of overhead and headaches for everyone...
Hope that helps,
Jeff
|
|
