|
Post by gericson on Jan 5, 2018 14:45:14 GMT
|
|
|
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.
|
|
|
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?
|
|
|
Post by gericson on Dec 8, 2017 13:17:45 GMT
Yes.
|
|
|
Post by gericson on Dec 7, 2017 14:50:29 GMT
Yes Additional Info: While legal JSON, it turns out that the original example is NOT legal in OData.
|
|
|
Post by gericson on Dec 7, 2017 14:32:35 GMT
Options: 1) Add SwordfishVersion to ServiceRoot 2) Add Term SwordfishVersion and annotate ServiceRoot and ServiceContainer with that value. 3) Add Term CompliesTo with a collection of SpecificationName and SpecificationVersion properties <Term Name="CompliesTo" Type="Collection(Core.CompliesToType)" Nullable="false"> <Annotation Term="Core.Description" String="List of specifications that this element complies to." /> </Term> <ComplexType Name="CompliesToType"> <Property Name="Specification" Type="Edm.String"> <Annotation Term="Core.Description" String="The name of the specification that this element complies to." /> </Property> <Property Name="Version" Type="Edm.String"> <Annotation Term="Core.Description" String="The version of the specification that this element complies to." /> </Property> </ComplexType>
#1 and #2 are problematic, since these do not cover vendor extensions. I recommend #3. It covers any specification and any element. We can specify that Swordfish implementations should (shall) use this term to annotate the ServiceRoot.
|
|
|
Post by gericson on Dec 7, 2017 14:06:37 GMT
No. ReplicaInfo is a property of Volume and has type StorageReplicaInfo. It describes a relationship between the Volume with that property as the source and the target identified by the contained Replica property of the StorageInfo property. It does not have a property called Source.
There is a new feature action that has been added to the Swordfish DataProtectionLineOfService schema. It is CreateReplicas. The new schema follows.
<ComplexType Name="ReplicaRequest"> <Property Name="ReplicaSource" Type="Resource.v1_0_0.Resource"> <Annotation Term="OData.Description" String="A resource to be replicated."/> <Annotation Term="OData.LongDescription" String="The value shall reference a resource to be replicated."/> </Property> <Property Name="ReplicaName" Type="Resource.Name"> <Annotation Term="OData.Description" String="The name of the new replica"/> <Annotation Term="OData.LongDescription" String="The value shall be the names of the replica."/> </Property> </ComplexType> <Action Name="CreateReplicas" IsBound="true"> <Annotation Term="OData.Description" String="This action creates an on-demand replica."/> <Annotation Term="OData.LongDescription" String="This action shall create an on-demand replica that conforms to the bound DataProtectionLineOfService."/>
<Parameter Name="ReplicaLineOfService" Type="DataProtectionLineOfService.v1_0_0.DataProtectionLineOfService" Nullable="false"> <Annotation Term="OData.Description" String="The data protection line of service this action is bound to."/> <Annotation Term="OData.LongDescription" String="The value shall reference the data protection line of service this operation is bound to."/> </Parameter>
<Parameter Name="ReplicaRequests" Type="Collection(DataProtectionLineOfService.v1_1_0.ReplicaRequest)"> <Annotation Term="OData.Description" String="Specifies the resources to replicate and a name for the replica."/> <Annotation Term="OData.LongDescription" String="Each value shall reference a source resource and provide a name for the replica."/> </Parameter>
<ReturnType Type="Collection(StorageReplicaInfo.v1_1_0.ReplicaInfo)"> <!-- <Annotation Term="OData.Description" String="The instance that represent the new replication relationships."/> <Annotation Term="OData.LongDescription" String="Each entry value shall represent the corresponding new replication relationship."/> --> </ReturnType>
</Action>
So: 1) Select an appropriate DataProtectionLineOfService instance. 2) POST to the CreateReplica Action on that instance. (Note the first parameter above is specified by the POST url. The second parameter is an array that names the source volumes and the corresponding replica names.) The implementation of CreateReplica is intended to create the replica using the information in the DataProtectionLineOfService.
|
|
|
Post by gericson on Oct 10, 2017 12:42:16 GMT
Yes, * locate the snapshot by navigating from the source Volume/ReplicaInfos(x)/Replica -> replica element, which in this case would be a Volume and where ReplicaInfos(x)/ReplicaType == "Snapshot" * Exposing the replica Volume is same as for any volume, place the replica volume into a StorageGroup.
|
|
|
Post by gericson on Oct 9, 2017 14:12:02 GMT
|
|
|
Post by gericson on Sept 29, 2017 14:38:27 GMT
On 1: Generally should be OK with all lowercase. Swordfish/Redfish/OData discourage name collisions based on case. Let us know if you find conflicts. On 2: The AnyOf syntax is used in the Redfish serialization of CSDL XML to Redfish JSON. It is expressing that the property is optional (i.e. the property may have no value. In that case, a json object for a type with that property might not contain the property, or it might be returned with the special indicator of null. For your serialization to Protobuf, consider simply ignoring the null option of the AnyOf statement. You could alternatively consider using the ODATA serialization of CSDL XML to CSDL JSON. That serialization produces a valid, but different JSON schema representation and does not utilize the AnyOf option. (see tools.oasis-open.org/version-control/browse/wsvn/odata/trunk/4.01 spec/examples/V4-CSDL-to-JSON.xsl) Note: This XSL is a work-in-progress. On 3: Consider using Protobuf Package and Import statements to minimize the size of Protobuf file for a particular schema. Each CSDL XML file corresponds to a Protobuf package. You should be able to coalesce the individual CSDL Schema declarations into a single Schema for each CSDL XML file. On 4: You don't need to include everything from Redfish or Swordfish. Each CSDL XML file contains include information that specifies the subset of schemas (packages) that need to be imported. In the Redfish JSON files that information is found in the $ref statements. In the OData JSON serializations, there are explicit $include statements.
|
|
|
Post by gericson on Sept 28, 2017 20:21:12 GMT
After pretty print, your schema does't look terrible. One change: The property names for Annotations should reflect the vocabulary schema that they belong to. You may need to add something to provide easy aliases. I Assume Context, Id, and Type are protobuf reserved words, but do you need them? I'm also not sure why you have patternProperties and additionalProperties listed at the level of ClassOfService. Note: Camel case used for Annotations. Note that properties below listed as Redfish.xxx or OData.xxx are annotations and not first class properties. Does Protobuf support annotations (i.e. metadata about the class (message). Lowercase used for OData attributes. (With apologies for syntax), For example:
message ClassOfService { string type = 1; // bytes patternProperties = 2; // bool addtionalProperties = 3; message Properties { odata.context = 1; odata.id = 2; odata.type = 3; message Oem { Oem $ref = 1; OData.Description = 2; OData.LongDescription = 3; } message Id { Id $ref = 1; enum OData.Permissions readonly = 2; bool Redfish.Required = 3 } message Description { oneof anyOf { OData.Description $ref = 1; string type = 2; } bool OData.Permissions readonly = 1; } message Name { Name $ref = 1; bool OData.Permissions readonly = 2; }
message Identifier { oneof anyOf { Identifier $ref = 1; string odata.type = 2; } bool OData.Permissions readonly = 1; string OData.Description = 2; string OData.LongDescription = 3; } message ClassOfServiceVersion { repeated string odata.type = 1; bool OData.Permissions readonly = 2; string OData.Description= 3; string OData.LongDescription= 4; } message LinesOfService { oneof anyOf { LinesOfService $ref = 1; string odata.type = 2; } bool OData.Permissions readonly = 1; string OData.Description= 2; string OData.LongDescription= 3; } } repeated string required = 4; string OData.Description = 5; string OData.LongDescription = 6; }
|
|
|
Post by gericson on Aug 16, 2017 17:30:31 GMT
mraineri: It is true that Redfish is silent on the use of OData capabilities that Redfish has not specified. Also, I agree with your response format since the referenced redfish schema does specify OData.AutoExpand for the Temperatures and Fans collections. So, the original question is correct w.r.t. OData syntax, but not correct for the referenced schema.
|
|
|
Post by gericson on Aug 16, 2017 16:55:34 GMT
Venkatesh Periyasamy: Creating a snapshot, (including schedule) is covered by values of the DataProtectionLineOfService. Inclusion of an instance of such a DataProtectionLineOfService into a ClassOfService entity, causes the ClassOfService to include that smapshot requirement. Finally, specifying that ClassOfService entity within a Volume, or FileShare, or StorageGroup, will cause the snapshot requirement to be specified against entity or included entities.
|
|
|
Post by gericson on Aug 16, 2017 16:47:18 GMT
Venkatesh Periyasamy: Swordfish will utilize the Redfish log and event services. There is work in progress to define specific messages. Please join Swordfish TWG to participate.
|
|
|
Post by gericson on Aug 16, 2017 16:34:50 GMT
Venkatesh Periyasamy: On StoragePool creation, the idea is to specify one or more ClassOfService entities. That and Capacity data structure specifies the desired amount of storage for Data, Metadata and Snapshots. Also whether storage is to be allocated thin or not. The choice of specific underlying storage is intended to be left to the implementation using that info. You could go farther and specify values for the CapacitySources property, but that is NOT the swordfish intention, since the goal is to push decisions about how the results are provided is intended to be pushed down to the implementation. On StorageGroup creation, there is a change queued up that will change the resource collections into simple collections. We've learned that the use of resource collections for these properties was overkill. The intention is that you can POST to create the StorageGroup as a whole.
|
|