|
Post by mraineri on Mar 1, 2019 20:38:47 GMT
The reason we call out that type of pattern property is for JSON Schema driven clients. Those types of clients aren't OData savvy and would be unaware of those types of properties (and possibly encounter errors if they are in the payload when not expressed in the JSON Schema).
|
|
|
Post by mraineri on Mar 1, 2019 15:42:28 GMT
That's a good point. While within Redfish we don't expect implementations to do this, we have usually been on the side of allowing folks to go outside of what's defined in Redfish to incorporate OData based extensions or features.
|
|
|
Post by mraineri on Feb 28, 2019 18:18:01 GMT
The other thing to note is at that level, I wouldn't necessarily expect to see the @odata.type property (or other sorts of annotations). Within the Oem object, I'd only expect to see properties in relation of the vendor name, IANA ID, or other identifier. That second regex may need to be removed.
|
|
|
Post by mraineri on Feb 28, 2019 18:06:39 GMT
That's a good catch. I'll have to think about this one a bit more and raise the issue with others, but I think you may be right.
|
|
|
Post by mraineri on Feb 14, 2019 21:25:23 GMT
Good catch! I've entered an issue in Github for the tool here: github.com/DMTF/Redfish-Tools/issues/180For future bugs like this (or other points of confusion), feel free to file an issue on Github so it becomes visible to the tools maintainers.
|
|
|
Post by mraineri on Feb 6, 2019 12:55:30 GMT
You're correct in that @odata.id is not valid in this case since the Event payload is simply a message sent to a client, and thus there is no URI to perform operations on. The JSON Schema definition should not contain @odata.id, and this will need to be fixed.
|
|
|
Post by mraineri on Jan 31, 2019 19:46:43 GMT
The reason it's done that way in schema is because it's possible to supply a GET request with the expand query parameter, like this: GET /redfish/v1/AccountService?$expand HTTP/1.1
HTTP/1.1 200 OK Content-Type: application/json { "@odata.id": "/redfish/v1/AccountService" "Id": "AccountService", "Accounts": { "@odata.id": "/redfish/v1/AccountService/Accounts" "Name": "Account collection", "Members": [ { "@odata.id": "/redfish/v1/AccountService/Accounts/0" } ] } } So, within JSON Schema definitions, the Accounts property resolves to an "anyOf" statement that is either an idRef, or the actual definition of the ManagerAccountCollection. Without the expand query parameter, you'll only get the idRef term, which is simply the "@odata.id" property. Query parameters are not allowed to be used on HTTP methods other than GET within Redfish.
You could have "Oem" within your definition of ManagerAccountCollection, but you'd not be able to use PATCH on it at the AccountService level since that only becomes accessible with the expand query parameter.
|
|
|
Post by mraineri on Jan 31, 2019 17:55:08 GMT
I'm not entirely sure what you mean by that; you cannot have "Oem" inside of "Accounts" like that. The "Accounts" property only contains a single "@odata.id" property. "Oem" as a property would be at the root level of the AccountService resource. So, if you had OEM extensions, it would look like this:
{ "Id": "AccountService", "Accounts": { "@odata.id": "/redfish/v1/AccountService/Accounts" }, "Oem": { "MyVendorName": { "@odata.type": "#MyOemNamespace.MyOemType", "OEMProp1": "...", "OEMProp2": "..." } } } So, you wouldn't PATCH the "Accounts" property at all; you'd PATCH "Oem" (and its subordinate properties):
PATCH /redfish/v1/AccountService HTTP/1.1 Content-Type: application/json { "Oem": { "MyVendorName": { "OEMProp2": "New Value" } } }
|
|
|
Post by mraineri on Jan 31, 2019 15:31:13 GMT
Read Only on the Members property is also intentional. This means you cannot directly modify the Members array with PATCH semantics. For example, this type of operation will fail:
PATCH /redfish/v1/AccountService/Accounts HTTP/1.1 Content-Type: application/json { "Members": [ { "@odata.id": "/redfish/v1/SomeNewURI" }, { "@odata.id": "/redfish/v1/SomeNewURI2" }, { "@odata.id": "/redfish/v1/SomeNewURI3" } ] }
PATCHing the Members array has similar semantics to PATCHing the Accounts property; these properties are just links and the Redfish Service is the decider in terms of how the URIs are allocated.
The control surface for collections is to perform POST on the collection (where the payload contains the new resource to add to the collection). PATCH isn't used for this because PATCH is for modifying existing properties, whereas POST is to provide a new resource. Since the "InsertRestrictions" term is set to "true" for ManagerAccountCollection, this means the client should be allowed to add new items to the collection via POST. Generally speaking, InsertRestrictions reflects if you're allowed to use POST, UpdateRestrictions reflects if you're allowed to use PATCH or PUT, and DeleteRestrictions reflects if you're allowed to use DELETE.
So, an operation like this should be allowed:
POST /redfish/v1/AccountService/Accounts HTTP/1.1 Content-Type: application/json { "UserName": "NewUser", "Password": "NewUserPassword", "RoleId": "Operator" }
|
|
|
Post by mraineri on Jan 30, 2019 22:07:54 GMT
In the case you're looking at, the property in question is a link to the collection (not the collection itself).
Within AccountService: { "Id": "AccountService", "Accounts": { "@odata.id": "/redfish/v1/AccountService/Accounts" } } So, the "Accounts" property is not writable. A PATCH operation on "Accounts" will be rejected. For example, this type of PATCH request will produce an error:
PATCH /redfish/v1/AccountService HTTP/1.1 Content-Type: application/json { "Accounts": { "@odata.id": "/redfish/v1/SomeNewURI" } }
The URI for the Accounts Collection will always be at "/redfish/v1/AccountService/Accounts".
|
|
|
Post by mraineri on Jan 9, 2019 14:22:28 GMT
This looks like an oversight with how this property is defined. Thinking about the use case you have, I tend to agree that null would make more sense for an unused slot instead of an empty string. We'll discuss this further in the forum.
|
|
|
Post by mraineri on Jan 8, 2019 19:19:50 GMT
The way to approach this is by using discovery via hypermedia. Prior to 1.6.0, there are a couple of standard URIs that work across all services. You can safely start crawling the service from the Service Root (/redfish/v1), and follow the URIs referenced in that resource, and subsequent resources as needed.
For example, one generic way to retrieve all thermal information is to perform the following: 1) Perform a GET on the Service Root resource (/redfish/v1) 2) Perform a GET on the URI referenced by the "Chassis" property in the Service Root resource 3) Perform a GET on each URI referenced by the "Members" property from the response in step 2 4) Perform a GET on the URI referenced by the "Thermal" property from the responses in step 3
You should be able to perform a similar methodology with regards to firmware update; you'd start at the Service Root, find the Update Service, find the Software Inventory components referenced by the Update Service, then perform Actions on each of the discovered Software Inventory components.
|
|
|
Post by mraineri on Nov 14, 2018 15:13:13 GMT
The decision about who assigns the addresses is really up to the implementation. As part of system initialization, I'd expect some sort of handshaking or occur between BIOS/UEFI and the management controller. As part of this, someone will allocate an IP address for the host and Redfish interface.
|
|
|
Post by mraineri on Nov 6, 2018 18:31:59 GMT
Yes, you will need to expose your OEM schema via the $metadata document. In addition to including the "OemTest" namespace, you will also need to include the "OemTest.v1_0_0" namespace. The general rule to apply is any namespace referenced by @odata.context and @odata.type needs to be included in $metadata. Some of these things (and others) are outlined in the Redfish and OData White Paper: www.dmtf.org/sites/default/files/standards/documents/DSP2052_1.0.0.pdf (section 5).
|
|
|
Post by mraineri on Nov 6, 2018 18:28:53 GMT
Hi Caffrey,
We've actually had similar feedback on this in the past. In the 2018.2 schema bundle, we removed the regex pattern on that property for use cases like you have described.
Thanks.
-Mike
|
|