fish
Guppy
Posts: 65
|
Post by fish on May 23, 2019 14:41:47 GMT
Thanks for you answer! See my comments inline below. I think the problem with changing these collections to allow Insert/Delete is a question of use case. We allow insert when you are truly creating. For example, a ComputerSystem is composed from existing resources by POSTing to the ComputerSystemCollection (based on the capabilities object). What we wouldn't want is secondary actions such as adding a chassis and a computer system automatically shows up. Besides, it sounds to me like you're wanting to use the Manger (for the Row/Rack)'s Northbound Interface to add stuff (which is really what would happen via the Southbound interface, like through Redfish or a provider/plug-in/some).Comment: Im not proposing that you would do POST/create operation to create Chassis with ChassisType Sled or RackMount. And certainly not also get an associated ComputerSystem instance created as side-affect. This should typically not be supported by any Redifish service. ComputerSystem and associated Chassis will typically be automatically discovered and automatically exposed in the Redfish API by the Redfish service. (These will be the "system created" chassis instances.) Im only proposing that schemas for Chassis and ChassisCollection should be relaxed by allowing Insert/Delete of Chassis via operations POST/create and DELETE, which would typically be used for ChassisType Rack or Row, for reasons mentioned. (These would be the "manually created" chassis instances.) What I read in your description is that you are aggregating other resources and are really looking to force discovery (either automatically go find resources because you know you added them or to manually add them based on something like an Address). So what you are telling your service is to go perform this discovery on this Address and then your Manager (bad name, so I'm going to start calling it an Aggregation Service) is going to go discover what resources can be added based on what is found at that Address. So you want to use the NorthBound interface to tell it to use it's SouthBound interface to find/proxy the Rows/Racks of equipment. Comment: Yes you are right in that this use case could be seen as an "aggregation service". But it should not be regarded as some kind of (automatic) "discovery scenario", or even manually triggered discovery. This is what I tried to explain in my initial post when I described that this aggregation service cannot automatically detect (discover) existence of Rows and Racks, because lower layer system (southbound systems) cannot detect these kind Row and Rack entities. I would guess that it is the normal case scenario that such systems does not have hardware or SW or sensors to detect e.g. how legacy servers are arranged in racks, and how these are arranged in rows in e.g. a data center. This is main reason why modelling of Row and Rack Chassis in the Aggregation service ("manager") would have to be accomplished by the northbound client/user of the Aggregation service Redfish API, by adding Chassis instances for Rows and Racks "manually" ( via POST/create operation towards the ChassisCollection). To me, this is more appropriately modeled as a Service with a Discovery action. Perhaps it is time for Redfish to document how Aggregation works and it seems that an Aggregation Service with some kind of action to force discovery through the Southbound interface would be an appropriate addition to Redfish.Comment: As stated above I dont think this kind of discovery action to force discovery through southbound interfaces would solve the use case I describe. Reason is the southbound systems are not able to discover/detect rows and racks and their relations in this scenario. And also in a hypothetical scenario where southbound systems would actually be able to do this kind of discovery/detection I would prefer that the discovery is automatic rather than manually triggered by some action. Generally I think that e.g. the Chassis resource is already suitable for describing aggregation of systems in an Aggregation Service , by supporting the containment hierarchy via ContainedBy and Contains properties.
|
|
fish
Guppy
Posts: 65
|
Post by fish on May 23, 2019 11:01:47 GMT
Specification 1.7.0 adds specification of "Dictionary file" naming in chapter 10.3. This chapter talks about "The binary file describing a Redfish Device Enablement Dictionary". Where can I find more information about these Dictionary files and their usage in Redfish? (Seems also that the URLs provided, such as "redfish.dmtf.org/dictionaries", are empty.)
|
|
fish
Guppy
Posts: 65
|
Post by fish on May 22, 2019 11:28:33 GMT
Hi,
Chassis can be of ChassisType Row and Rack. These ChassisTypes should be useful for describing the structure/arrangement of ComputerSystem equipment by using the Chassis ContainedBy and Contains properties with links to other Chassis resources.
Assume that a Manager (of ManagerType Service) is managing multiple ComputerSystems (with associated Chassis) that is arranged in Rows of multiple Racks. The Manager should expose a Redfish REST API including the correspond Chassis hierarchy. It is unlikely that this Manager or any hardware in this setup can automatically detect the existence of Racks and how they are arranged in Rows, at least by using any legacy hardware for servers and racks. So Chassis resources for Racks and Rows cannot be automatically created by the Manager (“system created”). And the Manager will likely also not be able to automatically populate the ContainedBy and Contains properties of Chassis for same reason. This means that Chassis for rack and rows would likely need to be added by end-user /client, e.g. doing POST/create operation towards the ChassisCollection resource. But ChassisCollection schemas has "Insertable" Bool="false" (and "Deletable" Bool="false" on Chassis), which should mean that POST/create on this collection and DELETE of Chassis is not allowed. So how could the Chassis of type Row and Rack be used in this scenario, if client/end-user is never allowed to create such Chassis? And Redfish schema modification rules does not allow to add operations to schemas, only to remove them (chapter 11.4 in 1.7.0). I guess one option is to abandon Redfish schema for Chassis and define own OEM schema for “OemChassis” but I would rather use the standard one in this case. Opinions?
Would Redfish consider to change to "Insertable" = “true” (on the Collection) and "Deletable" ="true" on Chassis?
I see a potential problem that the clients should preferably not be able to delete “system created” Chassis resources (automatically created and exposed by the Manager / Redfish service,) such as Chassis of type Sled or Rackmount. But this issue could probably be resolved by some new property “SystemCreated (boolean)” that is False for end-user created Chassis (such as for Raw, Rack), and not allowing DELETE of the SystemCreated Chassis instances. This would also be easy to add as Oem property in the Chassis for implementations that needed it. Other implementations could choose to have conventions that only Chassis with specific ChassisType can be deleted.
Other problem would be that ContainedBy and Contains in Chassis properties are readOnly. But I think updating of these could possibly be handled via (Oem) actions, if it would not be enough to set this at POST/create of the Chassis. (Even if providing full Link/URI to other resource is a little tricky. ) Any opinions on how to handle possible update (“PATCH”) of ContainedBy and Contains after Chassis was created?
BR /Magnus
|
|
fish
Guppy
Posts: 65
|
Post by fish on May 20, 2019 6:57:54 GMT
I never really understood why Swordfish/SNIA don't use separate namespace for the Sworfish schemas, but instead defines schemas is if they are Redfish-schemas, without "organisation" namespace. I find this a but confusing, especially since the swordfish schemas are not part of the Redfish schema releases. What is the reason? I guess separate org. namespace for Swordfish schemas would also make this kind of coordination between Swordfish and Redfish less needed? /Magnus
|
|
fish
Guppy
Posts: 65
|
Post by fish on Mar 27, 2019 13:29:31 GMT
OK, thanks!
|
|
fish
Guppy
Posts: 65
|
Post by fish on Mar 25, 2019 10:29:03 GMT
Hi, I would suggest that chapter 7.5.2.1 “Schema modification rules” is updated to allow also modifications of properties “Updatable” (Capabilities.UpdateRestrictions), “Insertible” (Capabilities.InsertRestrictions) and “Deletable” (Capabilities.DeleteRestrictions). I think that this will enable Redfish services to better describe its capabilities via schema in cases when some operation and/or read-write properties are not implemented by the specific Redfish service. And I assume this is in line with original idea of these “Schema modification rules”?
|
|
fish
Guppy
Posts: 65
|
Post by fish on Feb 15, 2019 7:27:31 GMT
OK, thanks for quick answer!
|
|
fish
Guppy
Posts: 65
|
Post by fish on Feb 14, 2019 15:56:36 GMT
Hi,
Im looking in the 2018.3 schema bundle. CSDL schema of “Resource” (Resource_v1.xml) describes that properties Location/Info and Location/InfoFormat (used in Chassis) are deprecated. Older versions of the corresponding JSON schemas (such as Resource.v1_7_0.json) also includes attribute “deprecated” for both Location/Info and Location/InfoFormat, but this “deprecated” attribute is missing for these properties in the new schema Resource.v1_8_0.json. Is this a bug in the new JSON schemas (and tool for generating JSON)? Or has format for deprecated properties changed in JSON? Or am I looking in the wrong place…?
|
|
fish
Guppy
Posts: 65
|
Post by fish on Oct 19, 2018 9:04:44 GMT
Some questions related to Tasks and Task payload.
1. Description of property StartTime talks about "The date-time stamp that the task was last started."Why is word "last" used here? I assume that a new separate Task resource is created each time a specific asynchronous operation is executed. So how could one Task resource instance be started more than once? Or is this only a problem with wording? (Same for EndTime)
2. Wording in sub properties of Task Payload suggest also that a specific Task can be restarted. Example: HttpOperation: "The HTTP operation to perform to execute this Task." This gets confusing in similar way I think. I would have preferred something like "The HTTP operation that initiated this Task." I assume that Payload object should expose which asynchronous operation that originally caused this Task resource to be created and exposed. (Which should be a one-time thing.) Could you please confirm that this is the intended usage of Payload object in Task resource?
Questions 1 and 2 comes down to the following question I think: Is a new Task created each time a specific asynchronous operation is executed? Or could the same the Task resource (same id) be "restarted" if the same asynchronous operation is executed again? I always assumed that there is always a new Task resource created (and new Task Monitor) for each asynchronous operation execution. Otherwise the execution outcome of the first operation would be lost if I execute the same asynchronous operation again... (Or is this actually implementation specific, and to be selected by the service provider/vendor?) If my assumption is still correct I think you should consider to rephrase these texts in the Task schema.
3. LongDescription of new property HidePayload ends with "If this property is not specified when the Task is created, the default value shall be False." What does this mean? I assume the end-users /clients cannot create Tasks explicitly, as Task resources are created automatically by the system/service when an asynchronous operation is initiated. So how can this default value be an issue if the Task can never be created (e.g. via POST on Task collection by API client)? I assume that the service provider (vendor) should select to expose the HidePayload value that is most suitable for each type of asynchronous operation?
4. Task Description in schema says "This resource contains information about a specific Task scheduled by or being executed by a Redfish service's Task Service.". Why is the word "scheduled" used? This could also indicate that Tasks resources are possible to be explicitly created by end-user /client, and then also scheduled to start at a specific time. But I assume that this is not the case. OK? Should not Jobs be used for this purpose?
|
|
fish
Guppy
Posts: 65
|
Post by fish on Oct 18, 2018 14:07:41 GMT
OK, thanks for your reply. I still think you should consider to clarify this specification text related to the usage of Task Monitor response status codes in the case of failure in the asynchronous operation. (Most importantly from server/service implementation view. May question was actually not about how to act as a client.)
|
|
fish
Guppy
Posts: 65
|
Post by fish on Oct 9, 2018 8:09:19 GMT
Any input on these questions? BR /Magnus
|
|
fish
Guppy
Posts: 65
|
Post by fish on Aug 23, 2018 11:35:54 GMT
Im trying to understand usage and purpose of property OemRecordFormat in resource LogEntry. Could someone clarify this please? Below is the description from Schema.
description: "If the entry type is Oem, this will contain more information about the record format from the Oem."
longDescription: "The value of this property shall represent the OEM specific format of the Entry. This property shall be required if the value of EntryType is Oem.".
First question is what “record” is? I would assume that it is the same as “LogEntry”. If so, is there some reason for the different terminology? (Or does "record" refer only to the Message property of the LogEntry?)
The example that can be found in online mockup for “Simple Rack-mounted Server with Local Storage”, but also in “Redfish Resource and Schema Guide”, confuses me a bit also. Here the property OemRecordFormat contains a value of “Contoso” at the same time as the property “EntryType” has value “SEL”. But the Description/LongDescription of OemRecordFormat only talks about usage when “EntryType” has value “Oem”. Is this example faulty? (The example does not contain any OEM extensions of the LogEntry as far as I can see.)
And what is then the intention of the OemRecordFormat? Should it contain some specific description/specification of the OEM specific format used for the Message property, or for the entire LogEntry? Or should it be only some kind of “reference” or “Id” of the LogEntry format? I found an example usage of OemRecordFormat in HPE ILO5. In this case it seems to be only some kind of free-text “Id” of the LogEntry format. But the actual LogEntry OEM extensions are specified via the HPE schema of the OEM extension, and schema indicated via property @data.type, so I don’t see much need for it here either. I expect also that the “Name” property of the LogEntry could give the same indication of which type of log this is. (Which is valid in the HPE ILO5 example at least).
|
|
fish
Guppy
Posts: 65
|
Post by fish on Aug 21, 2018 12:39:53 GMT
|
|
fish
Guppy
Posts: 65
|
Post by fish on Aug 17, 2018 8:32:00 GMT
Chapter “8.2. Asynchronous operations” in the specification states the following about Task Monitor for completed asynchronous operations: Once the operation has completed, the Task Monitor shall return a the appropriate status code ( OK 200 for most operations, Created 201 for POST to create a resource) and include the headers and response body of the initial operation, as if it had completed synchronously. If the initial operation resulted in an error, the body of the response shall contain an Error Response.
But this text only talks about the body of the response in case of error/failure scenario of the original asynchronous operation. HTTP status code to use in case of failure in the asynchronous operation is not explicitly described as far as I can see. Should I assume that the Task Monitor shall have a response with status codes, e.g. in series 400 or 500, corresponding to the failure reason of the original asynchronous operation? This seems to be a good approach as the Task Monitor would then be a clean “mirror” of the finished original asynchronous operation. But possible disadvantage with this approach could be that the client cannot distinguish between failure in the original asynchronous operation and failure in the Task Monitor request itself, at least based on the HTTP status code. (But maybe possible from error message in the Task Monitor response body.) What is the intended usage of the Task Monitor response status code in this case? Would you consider to clarify this in the specification?
|
|
fish
Guppy
Posts: 65
|
Post by fish on Aug 6, 2018 10:59:22 GMT
I assume that the word "should" is a key word in the discussed section: "Redfish Services should understand and be able to process ... is set to "No"". And I would then also assume that "should" means "recommended" or even "optional" in this case. But if the service chooses to supports these "no"-headers, it should do this according to the RFCs. Do you agree Jeff?
|
|