fish
Guppy
Posts: 65
|
Post by fish on Jun 26, 2018 8:17:14 GMT
Thanks for the inputs. I now get the get the difference between a "Profile", and what was meant by "Chinook". On the Intel PSME REST API front, my understanding is that it is more of a Profile (consisting of standard properties in a service, aliongwith a few Vendor specific options. Is this understanding correct? Thanks in advance, Manish Regarding Intel PSME (part of Intel RSD), I would denote this as an "OEM extension" of Redfish, and not a profile of Redfish. This was at least the case last time I looked. Intel PSME typically adds OEM specific properties to Redfish resources, and possibly some OEM specific resources. Intel PSME is not defined using the new profile constructs of Redfish.
|
|
fish
Guppy
Posts: 65
|
Post by fish on Feb 20, 2018 14:55:18 GMT
Hi,
OK, thanks.
1) I guess it will be up to the server providers (Redfish service) to worry about minimum deprecation period towards their clients. But it could result in that a server cannot migrate to use the newer Redfish schema, in case Redfish schemas are updated to exclude some deprecated property. The server provider can chose themselves when to not support the property anymore, by not returning it ni the response, as long as the deprecated property is still in the schema. So maybe the best solution, on Redfish schema level, is to keep the deprecated properties as long as possible, and leave it to the server providers to handle deprecation period. ?
|
|
fish
Guppy
Posts: 65
|
Post by fish on Feb 19, 2018 12:51:34 GMT
Hi, Regarding usage of deprecation annotation in schemas. An example is the deprecation of old Location/Info property in Resource schema (used in Chassis). I can find description of other annotations in the specification document DSP0266, but I can’t find any description of “Deprecated” annotation usage. Same for annotation of enum value deprecation via EnumDeprecated in JSON. (Example: IndicatorLED in ComputerSystem) Is this described somewhere? If not, I would like to propose that such description is added to the specification. This will also be valuable for organizations defining own OEM schemas as this will make it easier to follow same pattern for deprecation handling.
Related questions: 1. Are there any plans for how long the deprecation period will be for the deprecated properties, before they are finally removed from schemas (latest version)? Or will they never be removed? Should such statement be added to the specification also? 2. Is the any Redfish mechanism for deprecation of complete resource/schema? (Has this ever been applied in Redfish?)
|
|
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?
|
|
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?
|
|
fish
Guppy
Posts: 65
|
Post by fish on Feb 1, 2018 15:17:48 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?
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 …”
|
|
fish
Guppy
Posts: 65
|
Post by fish on Jan 17, 2018 7:34:44 GMT
OK, thanks!
|
|
fish
Guppy
Posts: 65
|
Post by fish on Jan 16, 2018 15:54:14 GMT
The concept of "ConsumingComputerSystems" and "SupplyingComputerSystems" works above the Composability level. Effectively the output of composing a ComputerSystem out of ResourceBlocks would result in a single ComputerSystem that behaves like a standalone unit, and there's typically some lower level hardware aspects at play for how these ComputerSystems are composed. Unfortunately we don't currently have mockups for this, but the "ConsumingComputerSystems" and "SupplyingComputerSystems" links start coming into play in scenarios like having a cluster, distributed system, or distributed application, and you need to express which standalone systems are playing a role in the application. This concept is really a more logical aspect of utilizing systems. OK, thanks. Then I would assume that both "Supplying" and "Consuming" systems can have systemType set to "Physical"? But then the only thing separating the "logical" / "consuming" system from a "supplying"/"non-logical" system will be the none-empty SupplyingComputerSystems Link. Do you know if it was ever discussed to introduce separate SystemType for such "logical" systems? E.g. systemType "logical"? Or could this maybe be candidate for future release? Would you agree on that this could be valuable for clarification and give easier separation of "logical" system constructs from ordinary physical systems?
|
|
fish
Guppy
Posts: 65
|
Post by fish on Jan 16, 2018 13:04:10 GMT
Hi,
Some questions related to ComputerSystem property SystemType = PhysicallyPartitioned.
This seems to be used for ComputerSystems in Resource – blocks when composing them into ComputerSystem with SystemType = Composed. (Looking e.g. at mockup “Bladed Partitions” in Redfish developer hub.) The Mockup describes the blade ComputeBlock (with SystemType PhysicallyPartitioned) as “represents PhysicallyPartitionedSystem ResourceBlock, from which System can be Composed”. But computerSystem schema LongDescription of enum PhysicallyPartitioned is “A SystemType of PhysicallyPartition is typically used when representating a single system constructed from one or more physical systems via a firmware or hardware-based service.", which indicates that rather the constructed (same as “composed”?) system should have system type “PhysicallyPartitioned”, which seems strange. Shouldn’t the composed system have systemType “composed”.. ? Can I assume that this enum LongDescription is a bit misleading, and should maybe be updated? How and when should the following new ComputerSystem properties be used? - “ConsumingComputerSystems” ("An array of references to ComputerSystems that are realized, in whole or in part, from this ComputerSystem."), - “SupplyingComputerSystems” ("An array of references to ComputerSystems that contribute, in whole or in part, to the implementation of this ComputerSystem."). And is there any dependency to the SystemTypes of involved ComputerSystems?
To me it sounds very similar to the use case for composed systems including “PhysicallyPartitioned” and “Composed” system types, but this use case uses Links properties of type ResourceBlock (from the Composed system) and Link ComputerSystem (from the ResourceBlock) according to Mockup “Bladed system”. Is there any tutorial, mockup or other description for “SupplyingComputerSystems” and “ConsumingComputerSystems”?
|
|
fish
Guppy
Posts: 65
|
Post by fish on Jan 8, 2018 7:35:51 GMT
OK, thanks. Yes, using collections with related resources seems to be they way to go, in case of too large Links arrays. But as soon I have the resource links in a collction I should not have to split it up in different collections, as collection can be read partially via paging query options $skip $top. But I guess splitting into several Links arrays could be an alternative to moving to a collection.
|
|
fish
Guppy
Posts: 65
|
Post by fish on Jan 5, 2018 15:11:32 GMT
OK. But I can find @odata.context, @odata.id and @odata.type defined as properties on "base" type Resource in schema Resource.v1_5_0.json, which uses reference to definitions of properties "id", "context" and "type" in schema odata.4.0.0.json.
These type definitions in odata.4.0.0 schema are also used for @odata.context, @odata.id and @odata.type properties in most other resource schemas such as ComputerSystem and Chassis as far as I can see.?
But why cant I find similar definition of "@odata.etag" in e.g. schema odata.4.0.0.json ? And why is not @odata.etag property included in ComputerSystem and Chassis (or other schemas) in same way as @odata.id and @odata.type properties?
|
|
fish
Guppy
Posts: 65
|
Post by fish on Jan 5, 2018 13:37:31 GMT
I find this in 1.3 specification:
6.5.4.4. ETag property ETags provide the ability to conditionally retrieve or update a resource. Resources should include an ETag property named "@odata.etag". The value of the ETag property is the ETag for a resource.
But I cant find @odata.etag in any (JSON) schema in schema bundle 2017.2. Where is it? Or is it missing?
I guess ETag header should be more important anyway?
|
|
fish
Guppy
Posts: 65
|
Post by fish on Jan 5, 2018 10:17:04 GMT
|
|
fish
Guppy
Posts: 65
|
Post by fish on Jan 5, 2018 10:08:57 GMT
Hi gericsson,
Thanks for very good clarification!
My concern for API clients was mainly related to a generic Redfish client trying to travers a complete Redfish service tree to find unique resources, only relying on the HTTP JSON responses. My conclusion from your above description is that the client cannot assume that collections will always contain unique resource instances, becausse same resource instance with same URI could turn up in many collections. So this client would have to check if members of a collection are "new"/unique or not. (Which should be no problem doing.) And the Links property could always be ignored when traversing a Redfish service for unique resourses.
|
|
fish
Guppy
Posts: 65
|
Post by fish on Jan 2, 2018 12:24:16 GMT
Hi Jeff,
Thanks for the links to this valuable info.
Yes I think it would be a good idea to add more info about how to extend the model, and also some more info on usage of "collections" vs "Links -properties". And I could also not find any information related to my original issue with "too large arrays" in Link-property. One thing that confuses me in this area is that it seems that Swordfish, which I was expecting to be a "simple" Redfish extension, have chosen a bit different application of Collections. (I´m involved in related thread in the separate Swordfish forum... :-)
BR /Magnus
|
|