|
Post by gericson on Feb 7, 2020 22:32:51 GMT
See ComputerSystem/Links/ConsumingComputerSystems and ComputerSystem/Links/SupplyingComputerSystems.
|
|
|
Post by gericson on Feb 3, 2020 16:11:19 GMT
I know that in our context, days seem really long. But... consider if you are trying to detect global warming... :-)
|
|
|
Post by gericson on Jan 28, 2020 21:54:16 GMT
A bit of background information. (see: docs.oasis-open.org/odata/odata-json-format/v4.01/cs02/odata-json-format-v4.01-cs02.docx)The OData TC has improved the language describing when to include count. It's still a bit hard to read. Here is the nub... count(odata.count) is considered by OData to be control information and thus is handled a little differently from annotations. If the client (3.1.1) specifies metadata= none, minimal or full, related count information for a collection property or navigation property must be included if it was requested (via $count in the request URL or via include-annotations in the Prefer header). Caveat: This requirement is specific to OData and may not be adopted by Redfish.
|
|
|
Post by gericson on Sept 11, 2019 16:20:58 GMT
That is certainly possible. You should propose to the feedback portal (https://www.snia.org/feedback) or if you are a member, to the SSM Technical Work Group (https://members.snia.org/wg/ssmtwg/dashboard) directly.
|
|
|
Post by gericson on Sept 11, 2019 13:18:50 GMT
StorageService and StorageSystem are not the same at all.
The term StorageSystem refers to a compute platform that hosts one or more StorageServices. Note, that there is StorageSystem is not modeled in the Redfish/Swordfish schema. Rather, a StorageSystem is represented by a ComputerSystem that has its HostingRoles property set to StorageServer.
The term StorageService refers to a service that provides advanced storage management functionality. The StorageService has a relationship to its hosting system (see NavigationProperty HostingSystem). The hosting system can be a simple, or complex computing platform, which could be provided by a chip or a cloud. The hosting system can also be a front-end to a cluster. Regardless, the hosting system is represented by either a Computer System or a Storage Controller.
As currently defined each instance of a ClassOfServiceCollection is contained (i.e. part of) an instance of StorageService. However, Swordfish does not say where each individual instance of ClassOfService is contained.
All of this is a long-winded way of saying that so far, the decision of whether or not an individual ClassOfService can be referenced by more than one StorageService is left to the implementation.
|
|
|
Post by gericson on Feb 14, 2019 14:23:47 GMT
Swordfish adds modeling for management of File Systems and File Shares to Redfish. Swordfish does not provide data path (read/write) access to individual files.
|
|
|
Post by gericson on Nov 20, 2018 14:41:15 GMT
On Insertability: Use of the OData InsertRestrictions and related annotations is still a work in progress. Currently these OData annotations only apply to EntitySets. Redfish schema is specifying this annotation on EntityTypes.
|
|
|
Post by gericson on Nov 20, 2018 14:22:54 GMT
A clarification first, then volumes.
The clarification: When ContainsTarget="true" is specified on an entitytype named xxxCollection, where xxx is the entitytype being collected, the containment is on the instance of xxxCollection and not on the collected entitytypes. Thus the list of collected elements is contained in the entity that declares the contained property and nothing is said about the collected elements (i.e. the corresponding Members collection).
On volume: The model supports three, possibly related collections of volumes. 1) In Storage: The Volumes collection lists volumes created by the storage subsystem represented by the Storage entity. A POST to this collection is a directive to the storage subsystem to create a volume.
If a StorageService manages the Storage entity, I would expect that the implementation would additionally add the new volume to the StorageService Volumes collection. If the implementation allocates the new volume from a StoragePool, then it should also be added to the StoragePool's AllocatedVolumes collection.
2) In StoragePool: The AllocatedVolumes collection lists volumes allocated from that storage pool. A POST to this collection is a directive to the storage service to create a volume from that StoragePool. Note: that a Volume may be created using space from more than one storage pool, but in this use the CapacitySources property should be null in the POST payload. This allows the StoragePool implementation to provide the needed capacity.
If the new volume is managed directly by a storage subsystem as in 1, it should also be added to that entities Volumes collection. The new volume should also be added to the StorageService that manages the StoragePool.
3) In StorageService: The Volumes collection lists volumes created by the storage service represented by the StorageService entity. A POST to this collection is a directive to the storage service to create a volume.
If the new volume is managed directly by a storage subsystem as in 1, it should also be added to that entities Volumes collection. If the implementation allocates the new volume from a StoragePool, then it should also be added to the StoragePool's AllocatedVolumes collection.
In all of these cases, the Volume payload in the POST must specify choices that are not left to the implementation.
|
|
|
Post by gericson on Oct 12, 2018 14:31:23 GMT
Hi, we are planning to add more info to the documentation and mockups. Here is my current understanding of how this all works.
Please let us know if this helps and with any suggestions for improvement.
Storage Groups Storage Group: A management element that defines a set of volumes for purposes of mapping to hosts, replicating, and managing consistency. [Note: Remove references on FileSystem, Object, File… from descriptions in StorageGroup.] Structural features The storage group has three primary collections: 1) Each volume in the storage group is represented as an entry in a MappedVolumes array property. - MappedVolumes []: Each entry that describes a volume referenced by this storage group. o LogicalUnitNumber: a string that represents the address of the volume when accessed from hosts attached to endpoints defined by a ClientEndpointGroup. o Volume: a reference to a Volume that belongs to this storage group. 2) Each the hosts are represented by entries in the ClientEndpointGroups collection. Each entry is itself a collection of EndpointGroups. Each entry in these EndpointGroups represents an endpoint of a host that will have access to the volumes of the storage group. - EndpointGroup o Identifier o GroupType: Indicates that this group represents storage client or storage server endpoints: Client, Server. o AccessState: All endpoints referenced by this endpoint group share the same accessibility . The states are Optimized, NonOptimized, Standby, Unavailable, and Transitioning. o TargetEndpointGroupIdentifier: If this endpoint group represents a SCSI target group, the value of this property shall contain a SCSI defined identifier for this group, which corresponds to the TARGET PORT GROUP field in the REPORT TARGET PORT GROUPS response and the TARGET PORT GROUP field in an INQUIRY VPD page 85 response, type 5h identifier. See the INCITS SAM-5 specification. o Preferred: Access via this group of endpoints is preferred. o Endpoints: A collection of endpoints 3) Each the hosts are represented by entries in the ServerEndpointGroups collection. Each entry is itself a collection of EndpointGroups (see above). Each entry in these EndpointGroups represents an endpoint of a storage server or network component that provides access to the volumes of the storage group.
Additionally, each storage group has the following attributes: - Identifier: A unique identifier in the context of the managed ecosystem that is persistent across instantiations of the manager (i.e. redfish service). Note: This is separate from the id property that represents the managed representation of the modeled StorageGroup. - AccessState: All volumes referenced by this storage group share the same accessibility to attached hosts. The states are Optimized, NonOptimized, Standby, Unavailable, and Transitioning. Different storage groups should be used to define alternate paths that have different access states to the same set of volumes. - MembersAreConsistent - VolumesAreExposed - Status: Health and state of the storage group o State: This value represents lifecycle state of the storage group. o Health: This value represents the health of the storage group related to delivering expected service to its clients. o HealthRollup: If this is a parent storage group, then this value represents health issues across any of the child storage groups. - Links: o ParentStorageGroups[]: Each storage group may be aggregated into other (parent) storage groups. This should be set by the implementation when a StorageGroup is added to a ChildStorageGroups collection in the parent. o ChildStorageGroups[]: A storage group may be an aggregate of one or more other (child) storage groups. o ClassOfService: A definition the service levels that must be provided by all volumes and over each of the connections of the storage group - ReplicaInfo: Describes this storage group in its role as a replication target. o ReplicaPriority: Governs the priority given to a background copy engine relative to IO from the host: Low, Same, High, Urgent. o ReplicaReadOnlyAccess: Governs who has read only access from the host: SourceElement, ReplicaElement, Both. o UndiscoveredElement: Describes whether the source or target is not modeled: SourceElement, TargetElement. (Note: Given model changes, this may be obsolete and if so, deprecated.) o SyncMaintained: If true, Synchronization shall be maintained o ReplicaRecoveryMode: Specifies when copy restarts after a broken link is restored: Automatic, Manual. o ReplicaUpdateMode: Specifies when target is updated: Automatic, Manual. o PercentSynced: Percent of work towards completing synchronization o FailedCopyStopsHostIO: If true, the storage array shall stop receiving data to the source element if copying to a remote element fails. o WhenSynced: Time o WhenActivated: Time o WhenDeactivated: Time o WhenEstablished: Time o WhenSuspended: Time o WhenSynchronized: Time o ReplicaSkewBytes: Maximum number of bytes that the target can be out of sync before switching to synchronous o ReplicaType: The kind of replica: Mirror, Snapshot, Clone, TokenizedClone. o ReplicaProgressStatus: Replication session status: Completed, Dormant, Initializing, Preparing, Synchronizing, Resyncing, Restoring, Fracturing, Splitting, FailingOver, FailingBack, Detaching, Aborting, Mixed, Suspending, RequiresFracture, RequiresResync, RequiresActivate, Pending, RequiresDetach, Terminating, RequiresSplit, RequiresResume. o ReplicaState: State of the replication relationship: Initialized, Unsynchronized, Synchronized, Broken, Fractured, Split, Inactive, Suspended, FailedOver, Prepared, Aborted, Skewed, Mixed, Partitioned, Invalid, Restored. o RequestedReplicaState: The requested state of the replica relationship, see ReplicaState. o ConsistencyEnabled: Indicates that consistency is enabled for this replica. (Note: with updated design, this property may be obsolete.) o ConsistencyType: A value of SequentiallyConsistent indicates that the source and target shall be sequentially consistent. o ConsistencyState: Indicates the consistency requirements of the source: Consistent, Inconsistent. o ConsistencyStatus: Current status: Consistent, InProgress, Disabled, InError. o ReplicaRole: (Note: This is obsolete and should be deprecated.) o Replica: A reference to the source of this replica o DataProtectionLineOfService: Defines desired level of service for protection RecoveryGeographicObjectives: Size of the fault domain Recovery PointObjectiveTime: Time Interval defining how much source data can be lost on failure ReplicaType: The kind of replica: Mirror, Snapshot, Clone, TokenizedClone. MinLifetime: Minimum life of the replica IsIsolated: True asserts that the replica is in different fault domain. Schedule: Applies to periodic replicas. ReplicaClassOfService: The class of service for replicas related to this StorageGroup. ReplicaAccessLocation: Where the Replica will be accessed from. This may be different from either the source or target location.
- ReplicaTargets []: An array of references to other resources (likely other storage groups), that are target resources that are replicas sourced from this storage group - AuthenticationMethod: with options of None, CHAP, MutualCHAP, and DHCHAP. - ChapInfo []: An array of entries used to authenticate the endpoints of this storage group o InitiatorCHAPUser: The username for CHAP authentication o InitiatorCHAPPassword: A write-only credential used as the shared secret for CHAP authentication o TargetCHAPUser: The CHAP username for 2-way CHAP authentication. o TargetPassword: A write-only credential used as a CHAP secrete for 2-way CHAP authentication. Behavioral Features Creating a StorageGroup POST /redfish/v1/StorageServices/<storagServiceId>/StorageGroups Request body: { Prototype storage group with as much filled out as possible. } Response: Location=/redfish/v1/StorageServices/<storagServiceId>/StorageGroups/<storageGroupId>
Changing the set of mapped volumes Replace MappedVolumes array as a whole. PATCH /redfish/v1/StorageServices/<storagServiceId>/StorageGroups/<storageGroupId> { "Id": "SG_abc_005", “MappedVolumes”:[ (“LogicalUnitNumber”: “0”, “Volume”: {“@id”: "/redfish/v1/StorageServices/1/Volumes/3"}), (“LogicalUnitNumber”: “1”, “Volume”: {“@id”: "/redfish/v1/StorageServices/1/Volumes/12341234"}), … ] ]
Creating an EndpointCollection POST /redfish/v1/StorageServices/<storagServiceId>/Endpoints Request body: { Prototype EndpointCollection with Members filled out with Endpoints that belong to this collection. } Response: Location=/redfish/v1/StorageServices/<storagServiceId>/Endpoints/<EndpointCollectionId>
Creating an EndpointGroup POST /redfish/v1/StorageServices/<storagServiceId>/EndpointGroups Request body: { Prototype Endpoint group with as much filled out as possible. } Response: Location=/redfish/v1/StorageServices/<storagServiceId>/EndpointGroups/<EndpointGroupId>
Adding a client endpoint group --- can be combined with other updates. --- PUT /redfish/v1/StorageServices/<storagServiceId>/StorageGroups/<storageGroupId> Request body: { "Id": "SG_abc_005", "ClientEndpointGroups”:[ One or more EndpointGroups, can be by reference, ( or I think this can be an upsert where the EndpointGroup is created here.) ] } Response:
Adding a server endpoint group --- can be combined with other updates. --- PUT /redfish/v1/StorageServices/<storagServiceId>/StorageGroups/<storageGroupId> Request body: { "Id": "SG_abc_005", "ServerEndpointGroups”:[ One or more EndpointGroups, can be by reference, ( or I think this can be an upsert where the EndpointGroup is created here.) ] }
Expose or Hide Volumes --- can be combined with other updates. --- PUT /redfish/v1/StorageServices/<storagServiceId>/StorageGroups/<storageGroupId> Request body: { "Id": "SG_abc_005", "VolumesAreExposed ”: true to expose and false to hide. This is an aggregate operation that includes all child storagegroups }
Replication The client must first select a DataProtectionLineOfService that specifies the service level requirements for the replication. Then the CreateReplica action is invoked to create a replica. Assume this is the selected DataProtectionLineOfService /redfish/v1/StorageServices(1)/DataProtectionLoSCapabilities/SupportedLinesOfService/OnDemandSnapshot
POST /redfish/v1/StorageServices(1)/DataProtectionLoSCapabilities/SupportedLinesOfService/OnDemandSnapshot/CreateReplicas() Request body: { "ReplicaRequests": [{ "ReplicaSource": {"@odata.id": "/redfish/v1/StorageServices/<storagServiceId>/StorageGroups/<storageGroupId> "}, "ReplicaName": "MySnapshot" }] }
This will create a snapshot relationship between the current storage group and a new storage group named MySnapshot (details are specified in the OnDemandSnapshot entry).
|
|
|
Post by gericson on Sept 20, 2018 12:42:16 GMT
Your suggestion is consistent with some implementations. In others a pool is factory that is able to create multiple types of volumes, file systems, or object stores. There are several possible ways to represent this. It would be good to have your participation in the Swordfish SSM TWG.
|
|
|
Post by gericson on Sept 19, 2018 13:50:49 GMT
Volume.VolumeType is being added in 1.0.7. We are providing this because we understand that many clients are familiar with selecting various raid levels.
With new storage architectures, the performance and robustness based on past experience with a RAID level may not be the best choice with newer implementations.
The ClassOfService/LineOfService datastructures are used to specify a desired level of service, regardless of implementation. For these reasons, RAID levels were intentionally omitted.
With this in mind, we encourage feedback on addition of attributes that can be used to specify levels of service in terms that an end user will understand and can measure.
|
|
|
Post by gericson on Sept 17, 2018 12:42:55 GMT
The use cases documented in the specification are examples of how the schema may be used, they are not meant to describe all possibilities. As specified in clause 5.1 Introduction, Swordfish extends the Redfish Scalable Platforms Management API Specification (DSP0266) from the DMTF. That specification documents the use of Delete relative to Resource Collections in general. This applies to Volume Collection, which is based on the Resource Collection declaration. For more information, see DSP0266, clause 6.4.4.6. Delete.
|
|
|
Post by gericson on Jun 25, 2018 21:17:22 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 See: odata-csdl-xml clause 13.2 EntitySet. Also see: odata-csdl-xml clause 13.3 Singleton. A Redfish ResourceCollection is NOT an OData EntitySet. Instead, a ResourceCollection is defined as an OData EntityType. Entity types based on ResourceCollection each contain a Navigation Property named Members that is defined as a collection of entities.
OData allows query parameters like $skip and $top on a GET against a URL that locates a collection of entities. (Like the Members property of a Redfish ResourceCollection.)
Redfish extends the semantics of a ResourceCollection to act as if it is the underlying Members collection.
OData further defines that a NavigationProperty that is qualified with the attribute ContainsTarget="true" implies either a Singleton or an EntitySet, depending on whether it is a scalar or a collection.
The clause 6.2 Entity Sets of the Swordfish specification is not a difference between Redfish and Swordfish. That clause is only meant to explain some of the above semantic nuances as defined in Redfish/Swordfish and as defined in OData.
|
|
|
Post by gericson on Apr 25, 2018 18:35:12 GMT
Some applications distinguish between null and an empty string. However, both simply indicate an absence of value. It should be equivalent to PATCH Manufacturer=null or Manufacturer=""
If a property is specified as Nullable="false", then a non-null (non empty) string must be supplied. For example from ComputerSystem_v1.xml: <Property Name="SystemType" Type="ComputerSystem.v1_0_0.SystemType" Nullable="false">
|
|
|
Post by gericson on Mar 14, 2018 21:20:03 GMT
Hi Leon. Following is additional information and clarifications that I hope will reduce your concerns. (see text taked with [GME])
1. From the schema definition, it's very clear to me that one ClassOfService contains multiple (five exactly) LinesOfService with different capabilities. [GME] Clarification. A ClassOfService may contain up to five different categories of service level requirements. Each category of service level requirement is represented by a zero or more corresponding ***LineOfService instances. Most likely, only DataProtectionLinesOfService will support more than instance, however the model does not enforce that.
2. From the schema definition, there is another schema called ***LoSCapabilties, and IMO it represents separate collections of LinesOfService with different types. [GME] Each xxxLoSCapabilities instance found in StorageServices represents the ability of the service to create and support new ***LineOfService instances that each represent a specific service level requirement. All currently defined and supported ***LineOfService instances should be copied into the ***xxxLoSCapabilities /SupportedLinesOfService collection.
3. In the UserGuide docs, A use case is that StorageAdmin has access to create line of service, and it turns out to send a PATCH request to update the correspond ***LoSCapabilities. [GME] The implementation of that ***LoSCapabilities. Should validate that the service is able to support each new or modified ***LineOfService instance added to the SupportedLinesOfService collection.
4. Another use case is that when StorageAdmin creates class of service, some new ***LinesOfServices are also inputted as the properties of new-created ClassOfService, but I didn't see any updates on ***LoSCappabilities. [GME] The implementation is responsible for validation and making the corresponding updates to the corresponding ***xxxLoSCapabilities /SupportedLinesOfService collections.
|
|