fish
Guppy
Posts: 65
|
Post by fish on Aug 26, 2022 12:06:00 GMT
Hi, Please also notice format of Oem action URI to use, like for "target" property in example above. Text from specification chapter 9.8.8 "OEM actions" below: "The URI of the OEM action in the target property shall be in the form: <ResourceUri>/Actions/Oem/<ResourceType>.<Action> ..." BR /Magnus
|
|
fish
Guppy
Posts: 65
|
Post by fish on Nov 11, 2019 9:51:17 GMT
Hi, I was also a little confused about this, as it is not very easy to find why "format" is used in json schema. (mraineri gives good description above about where it is defined). But I think that reason for using the "format" is likely in how CSDL schema files are translated to JSON schema files, but these parts I don´t think can be found in the specification document? (The CSDL files should be the origin and they are translated to JSON and openapi files.) Primitive data types (in CSDL files) are defined in specification (v 1.8.0) chapter 11.1.4.4, including type Edm.DateTimeOffeset, which I assume translate into some JSON string type but with "format": "date-time" added? And "format": "uri-reference" in JSON should in similar way originate from CSDL annotation term "OData.IsURL"? I hope that someone could confirm if this is correct or not.. I also think that this kind of mapping from CDSL to JSON could possibly be added to chapter 11.2 (JSON schema) in the specification to make it more clear? BR /Magnus
|
|
fish
Guppy
Posts: 65
|
Post by fish on Oct 17, 2019 11:55:07 GMT
Hi, I was looking at new event handling. E.g. reading in page 7+8 in powerpoint for “Redfish Events & Message changes in 2018.2”. www.dmtf.org/sites/default/files/Redfish_School-Events_2018.2.pdf Page 8 in presentation describes how to model clearing of “state-full” events/alerts. Using “ClearingLogic” property I can describe that one Event/Message will clear some other state-full Event/Message in the MessageRegistry file. E.g. as in the example where Message "ResourceErrorsDetected" is cleared by “"ResourceErrorsCorrected” according to: "ResourceErrorsDetected": { } "ResourceErrorsCorrected": { "ClearingLogic": { "ClearsIf": "SameOriginOfCondition", "ClearsMessage": [ "ResourceErrorsDetected“ ]} } Using this mechanism, I need to define two Messages for all state-full events/alarms in the MessageRegistry, one for the raise-event and one for the cease/clear event. But the Event also contains property Severity. I think this one should have values “Critical”, “Warning”,”OK”, even if there is only informal/textual reference for this string-type property to “Status” (“Health” property in Resource ?). A more simple solution for raise and clear of state-full Events would be to use only single Event Message, by setting Severity to “Critical” or “Warning” at raise, and sending same Event Message but with Severity set to “OK” when event is cleared. This solution can be used for all simple case with one-to-one mapping between events for raise and clear. Advantage with this solution is that I don’t need to specify double amount of Event Messages and I don’t need to specify the same trivial “ClearingLogic” for all of them. Can I assume that this “Severity-based” mechanism for raise and clear of events is also OK to use for a Redfish service? And maybe go for the more advanced features of “ClearingLogic-based” mechanism for raise and clear only when needed? I did not find anything about this in the specification document, and the PPT-file only described usage of ClearingLogic? And what is Severity=”OK” used for if not for clearing previously raised Event with same Message? Could you also consider including some more specific type definition of Event “Severity” property using some enum? BR /Magnus
|
|
fish
Guppy
Posts: 65
|
Post by fish on Oct 11, 2019 11:19:03 GMT
OK, thanks! I think I will assume this to become officially allowed later then... Looking forward to the formal decision and specification.
|
|
fish
Guppy
Posts: 65
|
Post by fish on Oct 10, 2019 9:02:02 GMT
Hi again, How to handle action response body for new OEM actions (and Redfish actions) is unfortunately still an issue I think. I was looking at Specification 1.8.0 chapter 7.10 to see if there was any updates, but the rules seems still to be that response body shall be empty or contain a Message that indicates either error or success. OK? But now I happened to look at some actions defined in Credential Schema (Rekey and Renew actions). These are defined in CSDL using "ReturnType" (and "actionResponse" in JSON schema), which seems to be used for defining parameters of an action response body. And these action response bodies seems to not consist of Message only...? (Same construct seems to be used also for actions response body in schema for CertificateService, and maybe more places?) So it almost seems that these new credential actions are not aligned to the Redfish specification of actions? Or is this some new action handling that was by mistake not yet added to the specification? Or am I misunderstanding this completely, or reading in the wrong place in the Specification...? Because this kind of mechanism for responding with some parameters (that are not only a Message) was what I was looking for before when I started this thread. Other related question: If now some actions may respond with "non-Message" body, can they still respond with Message in body in case of error? Should this be reflected in the schema of the response body in such case, so that "Message type" is alternative response type of the action? (It does not look like this in the Certificate actions I think?) BR /Magnus
|
|
fish
Guppy
Posts: 65
|
Post by fish on Oct 10, 2019 8:08:36 GMT
I would think that reducing scope should be okay. For example, if "Capabilities.InsertRestrictions" is set to true in the published schema, you should be allowed to set it to false. However, the reverse is not true; increasing scope is not something we've allowed to do for schema modifications. We can add this clarification to the spec. Hi again, One more question about schema modification (chapter 11.4 in Specification 1.8.0). I would assume that adding new URIs to the schema would also be an allowed schema modification? This would enable further reuse of standard Redfish schemas in OEM specific URIs. One example would for extended OEM usage of Redfish Certificate schema. (Usage of Certificates is currently restricted in the schema via Annotation Term="Redfish.Uris".) So I would propose that you add modification of the Annotation Term "Redfish.Uris" to the list of allowed schema modifications in chapter 11.4 also. BR /Magnus
|
|
fish
Guppy
Posts: 65
|
Post by fish on Sept 4, 2019 7:12:26 GMT
OK, thanks! BR /Magnus
|
|
fish
Guppy
Posts: 65
|
Post by fish on Sept 2, 2019 13:06:21 GMT
Hi, Seems that Description and LongDescription of property Message in resource/schema Settings is wrong. It looks like copy-paste-fault from LongDescription+Description of Message property of resource Task. I think that Descriptions of Messages array in Settings should be more inline with usage of Messages as described in chapter 9.9 of the specification (1.7.0). OK?
BR /Magnus
|
|
fish
Guppy
Posts: 65
|
Post by fish on Jun 24, 2019 8:42:00 GMT
Im actually somewhat surprised by your opinion and argument on this subject. To me the specification text is really specific about this subject, and I think that the specification includes a good description of a good principle. And I get really worried if you are considering to change the specification in some significant way here. I think also that many service implementations that use typical software libraries for json response serialization will want to keep such behavior where a resource will always return the same set of properties, as this should simplify implementation using the serializer. (Only that some of the properties are set to value null, when temporarily unavailable.)
Unfortunately I think that your proposed handling actually violates this part of the specification: "Properties not returned from a GET operation indicate that the property is not supported by the implementation.". If a service does not at all return EndTime for an ongoing Task, the client should then expect that the service will never respond with EndTime, even for completed Task. And I assume that this is not your intention. So such behavior will likely cause more problems for clients than returning null value in EndTime for ongoing Tasks.
Also I think that not having possibility to provide null in EndTime property is what will more likely force developer to provide strange EndTime values such as 00:00:00 or similar, as they should also want to comply to the other parts of the specification ("If an implementation supports a property, it shall always provide a value for that property."). Im not saying that properties that an implementation/service does not support should be populated with null values. Such not supported properties should never be exposed by the service even if they are in the schema. But in this case of EndTime we will want to expose it with with proper value for completes Tasks so we would need to expose it also for ongoing Tasks. (As for Jobs.)
I still think the EndTime for ongoing task and serialNumber for removed DIMM is typical scenario for "temporary unavailable" as you describe, and for this reason null value should be very suitable in these cases.
I really appreciate that you have provided null option for other properties where needed in all other properties in Redfish schemas where I have seen such need. So I hope that you will continue this in the future also.
I would once again want to urge you to add null option for EndTime in Task for previously stated reasons, as this should most likely not even be of any disadvantage for implementations that dont want to use it. But it would be of great help for us that think we need it for reasons of consistency and actually also for reasons of being compliant to the current specification. Otherwise I think that we may need to consider to add an OEM defined property in Task for EndTime including null option, which would be a bit odd.
I would also really like to hear opinions from other forum members on this subject.
|
|
fish
Guppy
Posts: 65
|
Post by fish on Jun 20, 2019 9:04:50 GMT
In the case where a Task is currently ongoing, I would expect "EndTime" to simply not be returned in the response payload. This is much like the case where you might have a DIMM not populated in a system, so properties like PartNumber, SerialNumber, and CapacityMiB are all not returned since the "State" of the resource is "Absent". Using null for the property value traditionally means that the property should be filled in by the service, but the service is unable to ascertain the value for the property. Hi, Unfortunately I dont really understand your arguments here. Too me the case of EndTime for an onging Task would be typical case of when a service cannot acertain a "normal" value and should instead provide null for this property. I think this behavior would also be consistent with how the Redfish specification describes how to handle such cases (some quotes below). Specification 1.7.0 chapter 9.5 "Properties" -Properties not returned from a GET operation indicate that the property is not supported by the
implementation. -If an implementation supports a property, it shall always provide a value for that property. If a
value is unknown, then the value of null is an acceptable value if supported by the schema
definition. Specification 1.6.1 chapter 7.5.6.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 think that your example with SerialNumber/PartNumber for not populated DIMM sounds also like typical case for exposing null in these properties. (I may have commented on this in similar forum discussion before also.) I would like you to add support for null in Task EndTime for these reasons, in order to allow Redfish implementations to adhere to such behavior if preferred. (I think adding null to the schema should be fully backward compatible change.) And it would be more consistent with EndTime of Job also.
|
|
fish
Guppy
Posts: 65
|
Post by fish on Jun 12, 2019 8:22:54 GMT
Hi,
Task property EndTime seems to have Nullable="false". This seems strange for an ongoing Task which should not have an EndTime yet. EndTime property of Job has Nullable="true", which I assume should be similar application of EndTime. Is this a fault in the Task CSDL? I would propose to change to Nullable="true" also for EndTime in Task in such case.
(I think also that the word "last" is a bit confusing in the Description of StartTime and EndTime. How could a Task be restarted? I would assume that each execution of an asynchronous operation should result in creation of new Task resource. OK?)
BR /Magnus
|
|
fish
Guppy
Posts: 65
|
Post by fish on May 29, 2019 11:27:19 GMT
OK, thanks! /Magnus
|
|
fish
Guppy
Posts: 65
|
Post by fish on May 28, 2019 7:13:52 GMT
Hi, Is there (or should there be) some file naming convention for oem message registry files? Similar as for oem schema files which should use "organisation" name as prefix in schema file names.
Related: I think that oem file schema (CSDL) naming rules is more difficult to find now in 1.7.0 specification (compared to 1.6.1). Previously (1.6.1) is was listed together with naming rules for other file types in chapter 7.1.1 ("Schema, registry, and profile file naming conventions"), with separate heading ("OEM schema file naming"). Now I found it "hidden" only in 9.7.3 ("OEM resource naming and URIs"). And chapter 10 "File naming and publication" references chapter 11.1.1 for CSDL file naming, but does not mention oem CSDL file naming as far as I can see.
|
|
fish
Guppy
Posts: 65
|
Post by fish on May 24, 2019 7:59:12 GMT
OK, thanks! (I would suggest that you add som kind of reference to such information to the Redfish specification, maybe in this chapter.)
|
|
fish
Guppy
Posts: 65
|
Post by fish on May 24, 2019 7:45:11 GMT
OK, thanks for your input! Will consider the different options further.
|
|