fish
Guppy
Posts: 65
|
Post by fish on Dec 22, 2017 13:00:05 GMT
I think that this chapter 6.2 "Entity set" is something that may differ between Redfish and Swordfish. I cant find this kind of "disclaimer" in Redfish specification. I think also that Redfish definition of collections means that collcetions should be regarded as entity set, modelling containment/child relations only, in same way as for entity sets on OData. (But Im not an OData expert..) Text from from OData spec: "An entity can be a member of at most one entity set". It seems that Swordfish for some reason choses to handle this differently, by stating that no entity sets are defined explicitely. I assume that this means that collections are NOT (always) entity set in Swordfish. Meaning that a resource may not be member of more that one collection in Redfish, but in Swordfish it can be OK to list one resource instance (entity) in mutiple collections. (This seems also to be used in Swordfish schemas and mockup.) In Swordfish it will be difficult to know which collation that actually conatins the resource (child/containement), but according to gericson in below thread this is intentional, and left to each implementation. Personally I prefer the Redfish way to handle this, even if this also has some disadvantages. See also possibly relate thread: redfishforum.com/thread/88/drives-volumes
|
|
fish
Guppy
Posts: 65
|
Post by fish on Dec 22, 2017 8:14:08 GMT
Hi Richelle, I think I already understand the differernt scope of Redfish schemas (physical) and Swordfish schemas (higher layer logical representations). This is not my concern. But a service should be able to expose both sets of schemas I think, and describe relations between them as discussed earlier in the thread. But Im trying to understand how to handle the differences between Redfish and Swordfish in how containement of resources are handled and modeled. (see descriptions from gericson above). According to his description Swordfish is not only a simple extension of Redifsh with only new schemas added. He is dscribing differences in what schema constructs mean (semantics). I would categorize these difference to be borderline protocol differences.? (Or at least general schema principle differences.) Im worried about how this could impact API clients. But Im also trying to understand who a service that exposes both schemas from Redfish and Swordfish should behave. (See also my questions in my previous post.)
|
|
fish
Guppy
Posts: 65
|
Post by fish on Dec 21, 2017 16:18:19 GMT
Hi,
Thanks for the reply.
I understand that StorageEnclosure1 should be a chassis resource and I also understand that exposing (physical) Storage like Drives is optional. But if you have references to the Drives, this example/mockup would be easier to understand if location (containment) of the Drives is better aligned to Redfish schema and Redfish application, which should result in something like: /systems/<id>/storage/drive/ as reference in StorageService Drive collection. Even if Swordfish shoulld be "more OData" and "less Redfish" in this aspect, if I understand you correctly...
I think it gets a bit complicated if Swordfish has a bit different principles for resources and schemas compared to Redfish, especially since Swordfish builds on top of Redfish. What rules will apply for schemas that are inherited from Redfish? Redfish rules or Swordfish rules? Redfish have defined different semantics for Link properties (referenced resources) and non-link / root properties (child /containment). Do you mean that these Redfish semantics do not apply also to a Swordfish system´s usage of the same Redfish schemas?
Maybe this issue is related to my other posting to the Swordfish forum? :-) redfishforum.com/thread/87/entity-sets
|
|
fish
Guppy
Posts: 65
|
Post by fish on Dec 20, 2017 15:52:08 GMT
Hi,
I have looked into this issue a bit more myself now so I thought I could post my findings so far. But I would still also like to have some comments or proposals from other forum members.
From looking into other Redfish and Swordfish schemas I have come the following conclusion: - Relations (other than child/containment) to other resources are not only included as references under Link property of the resource, they may also be included via child collection resources on top/root level of the resource. (The collection will in this case contain references to resources that are not child resources, but instead are contained/child in other collections.)
Examples of this can be found e.g. in: - ComputerSystem/HostedServices/StorageServices. (assuming these are contained in “redfish/v1/StorageServices ) - Drive/Volumes (assuming these are contained in “redfish/v1/StorageServices/<id>/Volumes) - Swordfish: StorageService/Drives etc (assuming these are contained in ComputerSystem/Storage/Drives)
This seems to be a possible “work-around” for my original issue, i.e. how to handled arrays in Link property (with related resources) that get to large. OK? Solutions is then to move them to be a non-Link property on root-level, and instead be a reference to a (child) collection that contains references to non-child resources. The collection will provide benefits such as support to $top and $skip. Would you agree to this conclusion?
Disadvantage with this pattern could be that original advantage with dividing resources properties into Link properties and other properties is partly lost. Because it is not possible to tell from a schema if collections outside Link property will contain reference to true child resources or if they will contain only references to items that has other parents. (I don’t think there are different types of collections for this pupose?)
Generally I think it would be a good idea to clarify the relations between resources in the specification somewhere. Specifically all parent-child (containment) relations should be good to clarify, e.g. via classical UML class diagram or via verbal description. Currently I think maybe the easiest way to find this out is to look at the mockups and make guesses based on the used URIs. (Because in most cases the URIs are built up to expose hierarchical child/containment relations.) But as URIs should be transparent, and no formal conclusion can be made from them, this is only a way to guess the intended hierarchy in an easy way. Formal specification would still be needed. Would you agree? I still assume that we want (and need) the information model / schemas to define the actual type of relations between resources? And specifically clarify child/parent relations. Description of these design choices and when to use which type of pattern (“Links-property” vs “Collection outside Links property”) for modelling of this type of relation (“non-child”) would also be good I think. (Currently I think only the “Links-property” way is described?) I think maybe also it would be a good idea to clarify that collections may include reference to contained/child resources, but also references to non-contained resources (that are actually child of other collection).
|
|
fish
Guppy
Posts: 65
|
Post by fish on Dec 19, 2017 16:08:14 GMT
Hi, Im trying to understand how the Swordfish model should work, and more specifically how it should be connected the “original Redfish” model. As a result I have some questions/issues related to the mockup included in Swordfish 1.0.5.
- StorageService/1 contains reference to collection of Drives, but the only included drive seems to be a reference to “/Chassis/StorageEnclosure1/Drives”, which does not exist, as no such chassis resource exist? But should this not be a reference to /systems/<id>/storage/drive/ instead? A chassis will also only contain reference to /systems/<id>/storage/drive/, because drives are child resources (containment) of systems/<id>/storage, and not child to Chassis resource? Currently the drives seem to be located as child resources to the Chassis “StorageChassis1” (assuming the URIs indicate containment hierarchy), but this seems strange, as the Drive should be child to /systems/<id>/storage/ instead. (Unfortunately files describing the Drives items and drives collection is missing under Chassis resource.)
- Regarding Volumes: I assume that these will be child to (contained by) the StorageService ? (and the Volumes are only referenced from Systems/<id>/Storage resource property, via a Volumes Collection containing only reference to Volume that is child of StorageService). OK? Also, it seems like Systems/<id>/Storage exposes array of volumes instead of link to collection of Volumes (as specified by schema?).
- Why is Volume schema included in both Redfish and Swordfish schema bundles? I assume it should be in only one of them in the end? Redfish?
|
|
fish
Guppy
Posts: 65
|
Post by fish on Dec 19, 2017 13:29:55 GMT
Hi, Text from chapter 6.2 in Swordfish specification below.
6.2 Entity Sets The Swordfish model does not currently expose any explicitly defined entity sets. OData specifies that an entity set is defined for each NavigationProperty that is defined as a collection and that has the ContainsTarget attribute set to true. In all other cases, Swordfish assumes that an entity set is defined globally within the implementation for each entity type. This is effectively the same as if the entity sets were explicitly defined in the ServiceRoot entity container.
I asume this does not mean that Swordfish does not defined "Resource Collections"? (as many such exist in the schemas..) Could someone explain what this means in practice? Examples? And what is different from "original Redfish"? (And why?)
|
|
fish
Guppy
Posts: 65
|
Post by fish on Dec 13, 2017 14:45:41 GMT
Hi,
I see from Redfish API specification (DSP0266 v1.3.0) section 6.5.4.8 “Links Property” that Links properties are either returned as reference to single related resource or an array of references to the related resources. I problems we can face when defining an OEM resource is that we want to reference many other resources, e.g. more than 50 or 100. This array could get very large. For resource collections, this problem is solved by that paging query options $skip $top. But from the specification I have concluded that collections should only be used for “containment” / “parent-child” relations, and not for other relations modelled via Links property. OK? So I assume that a Link property referencing a collection that includes Members reference to resources that are not child resources is not OK. Correct? Quote from specification: “For collection-valued reference properties, the value of the property shall be the array of related resource ids.” So how should I resolve this issue with too large arrays in Links property? We are thinking about removing these references completely, as they are double direction links in this case (compare with Contains and ContainedBy in Chassis), and rely only on the other direction Link. (Using single direction links only.) In absence of the too large array of references, similar functionality (to list the related resources) could possibly be achived via more advanced query support on the other resource. But I still think it is a problem that I haven´t found any practical solution in schemas for large number of references (in "Links") from one single resource.
Any comments or suggestions from anyone?
|
|
fish
Guppy
Posts: 65
|
Post by fish on Dec 11, 2017 7:33:01 GMT
OK, thanks!
|
|
fish
Guppy
Posts: 65
|
Post by fish on Dec 8, 2017 14:41:11 GMT
OK, thanks. Looking forward to this. (But I dont think I have access to DSP8010 2017.3a? Assuming this one is not publically available somewhere?)
|
|
fish
Guppy
Posts: 65
|
Post by fish on Dec 8, 2017 8:43:52 GMT
OK, thanks for the reply.
If similar situation would occur in the future I think it could maybe be a good idea to highlight this by stepping the major version of the schema to v2?
|
|
fish
Guppy
Posts: 65
|
Post by fish on Dec 8, 2017 8:25:36 GMT
Hi, To me it looks like some JSON schemas are missing in latest schema zip file: DSP8010 2017.2 Examples of missing schemas would be: Drive, Endpoint, EthenetInterface, Event, Fabric, HostInterface, etc. These schemas are present in 2017.1, but also on developer hub. redfish.dmtf.org/redfish/schema_index Corresponding XML schemas seem also to be present in metadata directory of 2017.2 Is this a mistake or in this intentional? I assume it is a mistake? E.g. as metadata (XML) schemas are included in 2017.2? And as the following is stated on developer hub schema index page: "A .ZIP archive (DSP8010) containing all of current schema files (both CSDL and json-schema) can be downloaded from the Redfish Standards page at: www.dmtf.org/standards/redfish"
Personally I think it is valuable to be able to download complete set of JSON schemas via single zip-file.
|
|
fish
Guppy
Posts: 65
|
Post by fish on Dec 1, 2017 13:08:57 GMT
Hi,
I think I have concluded the following from changes to Role schema. (OK?) In 2017.2 schemas the RoleId property was added to Role resource. This proerty is also annotated with requiredOnCreate, meaning that client will have to provide value at create (POST till role collection).
To me this looks like a none backward compatible change, beacuse clients that are not updated to the new schema yet will not provide the new property RoleId, and updated servers will reject POST/create without this property. In short: this will break in case of old client towards new server. Also I think that annotation "requiredOnCreate" is fairly new, so older clients (or not so advanced clients) would not understand this anyway.
Do you agree that this is actually not backward compatible? Or am I misunderstanding something here? Or how can I avoid backward compatibility issues here? (Scenario is to lift server implementation from older schemas to newest schemas.)
|
|
fish
Guppy
Posts: 65
|
Post by fish on Dec 1, 2017 8:08:00 GMT
I agree that cancel via delete of task mointor is better option than delete of task resource.
An additional potential problem with cancel via delete of task resource is that it may be a little unpredictable. If the client´s intention is to cancel the original operation this will be the result as long as the task is still in state Running, Response would be 200/OK, task resource is deleted and side-effect is that original asynch operation is also canceled. But if clients request is received by the server one second later and the task has already entered state Completed the response will still be 200/OK, task resource is gone and no side-effect of canceled asynch operation. So in this case the clint will not know if the operation was actually canceled or completed.? (Cancel of Completed task will be normal procedure for cleaning up old tasks from the task collection.) I guess above problem can maybe be resolved also via some E-tag handling, but this is not mandatory I think?
I still vote for cancel via action as long-term solution. Having this type of side-effect on delete of task monitor would not be the preferred semantics in my opinion.
|
|
fish
Guppy
Posts: 65
|
Post by fish on Nov 29, 2017 15:48:12 GMT
OK, sounds good that you will look into this more.
My personal opinion is that making this into a new “shall” requirement at this point could put a quite heavy implementation burden on existing server implementations that do not currently support such cancel operation. I would propose to make it into an optional/”should”/”may” requirement for this reason. Other reason is that we should not have more “shall” requirements than necessary, and I would consider this feature to be perhaps not the most important.?
I think also you should consider possible alternative solution for cancel of task via e.g. new action “cancel” on the task resource. Such solution would have the advantage that you can still track the tasks that were stopped via “cancel” in the task collection, and you can also see their state in the same way as for tasks that were Completed. (May need some new task state such as “Canceled”.) If you delete the task when you try to cancel it you also lose track of it. (Unless you get a new task for asynchronous delete of original task…) But also such solution should be optional in my opinion.
|
|
fish
Guppy
Posts: 65
|
Post by fish on Nov 29, 2017 7:59:11 GMT
This has been an outstanding item for the SPMF for some time. A proposal was made to us recently for how to show Action parameters in the JSON schemas, and this will be incorporated in the next release cycle of our schemas. OK, good news. Would this proposal be related to using Actioninfo from schemas ActionInfo.json, that can be found at least in 2017.1 schemas? I found this schema in the zip file, but I could not find any information on how to use it. Or is this described somewhere already?
|
|