|
|
Post by hanktsai on May 24, 2023 9:07:26 GMT
Have some implementation questions about POST StoragepoolCollection to create "storage pool" resource and POST VolumeCollection to create "volume" resource.
Q1.
Based on Swordfish_v1.2.4a_UserGuide.pdf, it describe mainly four ways to create storage pool, one of them is "7.1.18 Create storage pool using Specified Set of Drives and RAIDTypes". This method POST body include "SupportedRAIDTypes" and "CapacitySource1" properties, can I add more properties which not defined in "storage pool" resource(e.x. "Size", "WriteCachePolicyType", "ReadCachePolicyType"...), in order to use these additional properties to create "volume" resource simultaneously ?
Q2.
Follow Q1, can I create two new resource in one POST process ? (The scenario is like I described in Q1, POST to StoragepoolCollection, and create Storagepool resource and also Volume resource simultaneously.)
(I might think something wrong, please don`t hesitate to let me know.)
|
|
|
|
Post by Richelle Ahlvers on May 25, 2023 21:03:52 GMT
For Q1: You can add additional properties that are relevant to the POST request, but they need to be part of the StoragePool. The examples in the Use Case show a minimum required; most implementations have more supported properties that can be submitted as part of the request that will be valid.
Setting the "DefaultEncryptionBehavior", "DefaultDeduplicationBehavior", and "DefaultCompressionBehavior" would be good properties to set at creation time for a StoragePool.
For Q2: Creating a StoragePool does not typically automatically create a Volume within the StoragePool. Typically you will create the StoragePool, then create Volumes from the StoragePool. (Note that there may be implementations that may automatically create a default Volume when a StoragePool is created, but that would be an implementation-specific behavior, and not something defined within the standard.)
|
|
|
|
Post by hanktsai on May 29, 2023 5:26:38 GMT
For Q1: You can add additional properties that are relevant to the POST request, but they need to be part of the StoragePool. The examples in the Use Case show a minimum required; most implementations have more supported properties that can be submitted as part of the request that will be valid. Setting the "DefaultEncryptionBehavior", "DefaultDeduplicationBehavior", and "DefaultCompressionBehavior" would be good properties to set at creation time for a StoragePool. For Q2: Creating a StoragePool does not typically automatically create a Volume within the StoragePool. Typically you will create the StoragePool, then create Volumes from the StoragePool. (Note that there may be implementations that may automatically create a default Volume when a StoragePool is created, but that would be an implementation-specific behavior, and not something defined within the standard.) hi Richelle, thanks for your reply, it helps indeed. - Q3. Follow your reply for Q2, actually I meet a situation that might need to create a default Volume when a StoragePool is created. This is because I implement Swordfish with RAID card, and the library support this RAID card have the "drive group" concept, so I map the "drive group" concept to "StoragePool" concept. But here is the problem, the library support this RAID card can only create virtual drive(Volume), and simultaneously this new virtual drive(Volume) belongs to a drive group(StoragePool), there is no method to only create a drive group(StoragePool) with no virtual drive(Volume) exist. So for this situation I described, I might need to implement 1 of 2 below methods : (1) POST to create a "StoragePool" with additional properties(e.x. "Size", "WriteCachePolicyType", "ReadCachePolicyType"...) not be part of the StoragePool, these additional properties are used to create Volume simultaneously. (But refer to your reply, it is not valid.) (2) I need to maintain a "virtual storagepool", so when I POST to create a "StoragePool", this kind of "virtual storagepool" being created(RAID card did not know "virtual storagepool" exist at this moment). And wait for next action, POST to this "virtual storagepool" in order to create Volume(Now RAID card create volume). Q4. Follow Q3, I think there might be some reasons that specification request or suggest to create StoragePool first, then create Volume ? If it is possible, please give me some hints. (Because refer to RAID card library I used for developing Swordfish, this scenario seems not suitable.) Thanks you so much. |
|
|
|
Post by Richelle Ahlvers on May 30, 2023 16:32:03 GMT
For Q3: There aren't properties defined in the Swordfish StoragePool schema currently for the examples you have noted (size, WriteCachePolicyType, WriteCachePolicyType). The only defaults that are available are for Compression, Encryption, and Deduplication (and ClassOfService). However, you can pass the volume-specific properties as Oem properties. Oem properties could be defined similarly to these DefaultXXBehavior in an Oem schema, or more directly as explicit properties.
If the implementation cannot separate the action of creating the storage pool from a separate action to create the initial volume, the implementation could use the information passed using Oem properties in the StoragePool POST to then "automatically" create a volume from the POST request to create StoragePool.
|
|
|
|
Post by hanktsai on May 31, 2023 3:17:50 GMT
For Q3: There aren't properties defined in the Swordfish StoragePool schema currently for the examples you have noted (size, WriteCachePolicyType, WriteCachePolicyType). The only defaults that are available are for Compression, Encryption, and Deduplication (and ClassOfService). However, you can pass the volume-specific properties as Oem properties. Oem properties could be defined similarly to these DefaultXXBehavior in an Oem schema, or more directly as explicit properties. If the implementation cannot separate the action of creating the storage pool from a separate action to create the initial volume, the implementation could use the information passed using Oem properties in the StoragePool POST to then "automatically" create a volume from the POST request to create StoragePool. hi Richelle, thanks for your reply, further questions ! For Q4 : Any suggestions, any would be appreciate ? : ) Q5.Follow your reply, I check on the Redfish Spec DSP0266_1.18.0.pdf. For the POST operation, when using the (HTTP 201 Created) status code as response, if a response body is provided, what should I provide into the response body ? (Normally it contain the newly created resource, but now I create "StoragePool" & "Volume" simultaneously) Q6.Follow Q5, what "Location Header" should I used for reply ? (Normally it is the newly created resource uri, but now I create "StoragePool" & "Volume" simultaneously) Q7.I think the scenario I encountered is not rare, is it possible to become a spec standard(not oem) that we can add "Volume related properties" to the body as POST to create StoragePool, and the "Volume" is created simultaneously. (or add other new use cases to introduce other ways to create volume / storagepool, which not binding these two resources when creating) |
|
|
|
Post by Richelle Ahlvers on Jun 6, 2023 15:18:42 GMT
For Q5 - the response body needs to respond with just the StoragePool information. If there is relevant content reported by the implementation in an Oem section, it can return that as well. However, again, the POST just requested a creation of a StoragePool, so the response should only return info on the creation of the StoragePool instance. Q6 - same as Q5. Return the URI of the StoragePool. Q7 - if there are multiple companies / implementations that are interested in extending the Swordfish spec to include more properties for these use cases directly in the standard version of StoragePool, please join the SNIA SSM TWG to contribute directly. You can also submit via the SNIA feedback portal: www.snia.org/feedbackThanks, Richelle |
|
