|
|
Post by ratagupt on Jan 30, 2019 10:54:54 GMT
Hi,
In most of the schemas, we have the properties which are of type Collection, it is defined as readonly = true. eg: AccountService schema having accounts property which is of collection type and it is readonly = true.
Does that mean I can not perform a POST request on the accounts?
What is the mean of readonly = true for the collection object?
The similar behavior I saw for the certificates in the ManagerAcount schema..where it is defined as readonly=true.
Ratan
|
|
|
|
Post by jautor on Jan 30, 2019 16:00:42 GMT
The readonly annotation indicates that the property itself is read-only, which means the link to the ManagerAccountCollection cannot be changed.
But yes, what you want to do is create/modify/delete a member of that collection, which is done using POST/DELETE operations on the collection. If you look at the schema definition for ManagerAccountCollection, you'll see "insertable=true" in the JSON-schema (and under "InsertRestrictions" in the CSDL).
I'll take a look to see if there's a way to better surface those Collection capability details in the schema documentation. As there aren't a lot of collections that users can add/modify/delete, perhaps we just need to add statements to the descriptions in the links to them that say something like "ManagerAccounts can be created or deleted by performing operations on the Collection."
Jeff
|
|
|
|
Post by ratagupt on Jan 30, 2019 19:01:04 GMT
Jeff, Thanks for the reply, I am confused here that some property is of type complex object,(in this case it is a collection) which is readonly but I can perform an operation on that object. I feel that readonly property on the collection object should be false and then in the Collection capability details, we can mention that what operation can be performed.
|
|
|
|
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 ratagupt on Jan 31, 2019 13:36:18 GMT
Hi Mike, Thanks
But seems in redfish we have the read only property for the collection sub property also.
Now in the below request, I have made the URL till "Accounts", will the PATCH request work now?
PATCH /redfish/v1/AccountService/Accounts HTTP/1.1
Content-Type: application/json
{
"@odata.id": "/redfish/v1/SomeNewURI"
}
I hope that It should work as the readonly property is not true for @odata.id but it is true for other properties "Description" and "Members".
In the ManagerCollection.json it is explicitly mentioned that property "Description" or "Members" is readonly, so that suggest I can not perform the following PATCH request
PATCH /redfish/v1/AccountService/Accounts HTTP/1.1
Content-Type: application/json
{
"Description": "TestDescription"
}
|
|
|
|
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 ratagupt on Jan 31, 2019 17:14:16 GMT
I understand that members property can't be patched. My point was if parent property is marked as readonly, then subproperties of this parent property should not be changed through PATCH.
I am assuming that oem property of accounts can be patched as it is not set as readonly.
PATCH /redfish/v1/AccountService HTTP/1.1
Content-Type: application/json
{
"Accounts": {
"oem":
{ "Prop1":"/redfish/v1/SomeNewURI"}
}
}
If oem property of accounts can be patched, then accounts property in the AccountService marked as readonly creates confusion.
|
|
|
|
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 ratagupt on Jan 31, 2019 19:15:39 GMT
Did I misunderstand the redfish.dmtf.org/schemas/ManagerAccountCollection.json? "Accounts" in the redfish.dmtf.org/schemas/AccountService.v1_3_1.json is of type "ManagerAccountCollection". I can see that oem is property of ManagerAccoutCollection which in turn becomes the property of accounts. I see that oem property exist in the account service but it also exist for the ManagerAccountCollection. what I was referring that oem under accounts(ManagerAccountCollection). I am not sure why you mentioned that oem cannot have inside accounts. |
|
|
|
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 ratagupt on Feb 4, 2019 18:16:42 GMT
Thanks for explaining it, I understand that I can't perform the PATCH request from AccountService but can I perform the following request from accounts property?
Content-Type: application/json
PATCH /redfish/v1/AccountService/Accounts HTTP/1.1
{
"Oem": {
"MyVendorName": {
"OEMProp2": "New Value"
}
}
}
|
|
|
|
Post by jautor on Feb 4, 2019 23:27:08 GMT
Thanks for explaining it, I understand that I can't perform the PATCH request from AccountService but can I perform the following request from accounts property? Content-Type: application/json PATCH /redfish/v1/AccountService/Accounts HTTP/1.1 { "Oem": { " MyVendorName": { "OEMProp2": "New Value" } } } That would be a PATCH to an "Oem" object within the ManagerAccountCollection resource. The Collections are marked as "updateable=false" so no, a PATCH would fail. While placing OEM properties in a Collection resource is allowed by the specification, as defined currently they must be read-only. Regardless, I would recommend that you place those OEM properties in the AccountService resource instead. As account management is the purpose of that resource/service, it should be clear to the client/user that any OEM properties there would be related to the Accounts... Jeff |
|
|
|
Post by ratagupt on Feb 5, 2019 10:04:30 GMT
Thanks Jeff, That suggest that if Collections are marked as "updateable=false", so no need to look at the read only property of the collection subproperty. This was the confusion.
|
|
