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?
|
|
|
|
Post by gericson on Dec 20, 2017 22:07:36 GMT
1) 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?
[GME] No. 'StorageEnclosure1' is intended to be a Chassis resource (see Redfish Mockups). The Drives are to be part of that. 'Storage' is a resource that represents a physical storage subsystem. This may or may not exist in a Swordfish world. Swordfish relies on a logical storage service model represented by 'StorageService'.
2) 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?
[GME] Swordfish does not insist on presence of Storage. It includes a DriveCollection within StorageService. This allows all of the drives known to be located via that collection.
3) 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.)
[GME] From an OData point of view (but not Redfish), containment of the Drives is not defined, since the containing EntitySet is unspecified. Therefore, whatever strategy the implementation chooses to use is OK. In the Swordfish case, this is also true, since the DriveCollection does not specify the EntitySet for the member drives.
4)- Regarding Volumes: I assume that these will be child to (contained by) the StorageService ? Generally yes. But could also be contained by a 'Storage' subsystem. Same OData issue w.r.t. containment as with drives above, it simply is left to the implementation.
5) 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?
[GME] In Swordfish world, assume that the Volume entity is defined by the StorageService, and referenced elsewhere.
6) Also, it seems like Systems/<id>/Storage exposes array of volumes instead of link to collection of Volumes (as specified by schema?).
[GME] The mockup for /redfish/v1/Systems/3/Storage/HA-RAID/Volumes is correct.
- 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 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
|
|
|
|
Post by Richelle Ahlvers on Dec 21, 2017 21:00:25 GMT
Swordfish doesn't have different principles for resources and schemas. Swordfish is an extension of Redfish.
However, Swordfish has different expectations for which schema to use to represent a storage system. Refer to the overview in section 5 of the Swordfish specification for background here. To follow up on George's point above, you will see that the model described there does not include the redfish "Storage" schema.
The redfish "Storage" schema is predominantly used to describe configurations where storage subsystems are physically connected (e.g., plugged into) computer systems. This physical model does not apply to any external storage systems. It would apply to direct-attach storage configurations only. (Note: it is identified future work for the Swordfish community to better document how these configurations work with StorageServices.)
For the questions related to delivery of the Volume schema: Volume was originally developed by Redfish in the DMTF, but when Swordfish was developed and needed to extend it, Redfish gave ownership and maintenance responsibilities to Swordfish. The versions delivered by Swordfish contain all of the requirements for both Redfish and Swordfish.
Thanks,
Richelle
|
|
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.)
|
|
|
|
Post by mraineri on Jan 4, 2018 17:43:26 GMT
As far as Volumes are concerned, an implementation can have a set of Volumes that belong to a Storage resource under a given ComputerSystem and can also have a set of Volumes that belong to a StorageService. This is like how both Managers and ComputerSystems have their own LogService; each are independent and can contain their own unique resources. Depending on what type of service you're creating, you may have both sets of Volumes in your service.
In terms of which version of Volume to use, it's largely going to be implementation specific. I imagine newer implementations will only use the Swordfish definition; we always encourage new development to use the latest version of each schema, as they're all backward compatible. The reason we still have the older 1.0.X version in the Redfish package is because implementations may have been created prior to the transition of the Volume schema to SNIA; removing it from the DMTF package would break these existing services. However, either version will be usable in either the Volumes subordinate to Storage, or the Volumes subordinate to StorageService.
|
|
|
|
Post by gericson on Jan 4, 2018 22:25:20 GMT
Feedback to fish: The Redfish/Swordfish model is able to expose both physical and logical resources and relationships between them. Redfish and Swordfish schema use the same containment model. The following are true across both Redfish and Swordfish schemas: By Redfish convention, a Links ComplexType, contains only NavigationProperties with the ContainsTarget attribute not specified. The default value is False. Thus all resources referenced in a Links ComplexType are contained elsewhere. By Redfish convention, all other declarations of a NavigationProperty in any other EntityType or ComplexType declaration represent containment only if the ContainsTarget attribute is explicitly set to True. If the value of the ContainsTarget attribute is not specified or is set to False, containment is left to the implementation for both Redfish and Swordfish. (Note that this applies to the Members NavigationProperty of all declared RedfishCollection subtypes.) The above should clarify that resources modeled by either schema behave the same with respect to containment. Normal UML rules apply to inheritance. Since we don’t override properties or methods, you should not see any change in behavior. On your question w.r.t. Drives and alignment to Redfish: Collections of Drives are found in several Redfish/Swordfish schema declarations: Chassis, PCIeFunction, Storage, StoragePool, and StorageService. All of these declarations may be used separately or together. In all of these schemas, the referenced Drives are not explicitly declared to be contained. Therefore, if multiple of these resources reference the same drive, containment is still up to the implementation. This should not be an issue for a client, since both Redfish and Swordfish recommend that a client should not assume they know how to create a URL. Except for the few well-known URLs (i.e. /redfish/v1), a Redfish/Swordfish client must always use URLs that are returned by the service. |
|
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.
|
|
