fish
Guppy
Posts: 65
|
Post by fish on Feb 12, 2018 12:37:31 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.”
To me this looks like different handling for directly applied PATCH on “Current configuration object” and PATCH via Settings Data. Do you agree? Why is this specified to be handled differently in such case? To me the simpler solution would be that clients shall only issue PATCH on properties exposed by the service via GET.
Second bullet of same chapter 7.8.2 says “The support of a specific property in a resource is signaled by the presence of that property in the Current Configuration object. If the element is missing from Current Configuration, the client may assume the element is not supported on that resource.” How should I understand the word “may” here? I think it would be easier if this was a “shall”, according to my argumentation above. And first sentence in same bullet does not include any “shall” or “may”, which I think makes it difficult to understand the intention. Could someone please clarify?
|
|
|
|
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 |
|
fish
Guppy
Posts: 65
|
Post by fish on Feb 15, 2018 12:49:28 GMT
Hi Jeff,
Thanks for your answer! And good that you will look into clarification in this area.
Im not concerns about that PATCH on unsupported single property would be allowed, and result in that this property is created. (As you say, should not be supported.)
Im more concerned about PATCH on unsupported property, as part of multiple property PATCH, together with actually supported properties. I don’t think this can be handled exactly in the same way as PATCH of ReadOnly properties together with supported actually properties. Reason is that the “error handling” specified in section “6.4.4.3 Update PATCH”: “In the case of a request including modification to several properties, if one or more properties in the request can never be updated, such as when a property is read only, an HTTP status code of 200 shall be returned along with a representation of the resource containing an annotation specifying the non-updatable property. In this success case, other properties may be updated in the resource.”
Such annotations can be provided for supported (ReadOnly) properties, but I cant see how you can expect a service to provide annotations on properties in the response body for properties that the service does not support. So I think multi property PATCH operations including none supported properties may need special attention? Would failure for the unsupported properties result in annotation on the top level resource instead of on single ("none existing/supported") property? Maybe an example would be good in such case.
In your example with properties related to the NetworkDeviceFunction, which is changed to Ethernet type, I think that the properties related to Ethernet are actually supported by the Service. But they don’t have valid value as long as the FibreChannel type is applicable. So in this case, when type is still FibreChannel, I think that the service should expose also the Ethernet related properties, but with value set to null. This means that these properties should always be exposed. This will also make it easier for the client to know that they are actually supported by the service (but currently dont have valid value) and can be updated with PATCH. I think this is described in section “7.4.4.5. Required properties”: “If an implementation supports a property, it shall always provide a value for that property. If a value is unknown, then null is an acceptable values in most cases. Properties not returned from a GET operation shall indicate that the property is not currently supported by the implementation.” I understand this as properties should actually not “come and go” , they should always be there, but possibly with value null. OK?
|
|
