docs/testplan: Adding a testplan for Server Side Copy (#4317)
testplan: Adding a testplan for Server Side Copy This is a testplan for Server Side Copy that follows the testplan template.
This commit is contained in:
nadimhq
GitHub
parent
d611c16891
commit
952f50e6e3
50
docs/testplan/server-side-copy-testplan.md
Normal file
50
docs/testplan/server-side-copy-testplan.md
Normal file
@ -0,0 +1,50 @@
|
||||
# Server Side Copy Testplan
|
||||
|
||||
|
||||
|
||||
## Background
|
||||
This testplan is going to cover Server Side Copy. We want it to be an atomic operation; it should have no decrypt/encrypt operations, it should only copy committed objects, it will avoid downloading and re-uploading and should be a fast operation.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
| Test Scenario | Test Cases | Description | Comments |
|
||||
|------------------------|--------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------|
|
||||
| Other Services | Impact on Audits | While audits are running, it should be possible to server side copy with no negative impact on former services | |
|
||||
| | Impact on Graceful Exit | While graceful exit is running, it should be possible to server side copy with no negative impact on former services | |
|
||||
| | Impact on Garbage Collection | While garbage collection is running, it should be possible to server side copy with no negative impact on former services | |
|
||||
| | Impact on Data Repair | While data is being repaired, it should be possible to server side copy with no negative impact on former services as data repair should ignore segments with a set ancestor_stream_id | |
|
||||
| | Impact on Metainfo > Expired Deletion | While metainfo loop is going through expired deletion, it should be possible to server side copy with no negative impact on former services | |
|
||||
| | Impact on Accounting/Tally | While accounting services are running, it should be possible to server side copy with no negative impact on former services | |
|
||||
| | <s>Expiration Dates</s> | <s>For server side copy users are allowed to make new copies of pieces which allows users to change their expiration dates, so in this way users are able to change expiration date of the new object through server side copy</s> | This won't be possible as currently designed, as storage nodes will delete the pieces on the original expiration date. |
|
||||
| DB- Table Segment | Expiration Date | If a user uses Server-side copy, then the source object and the destination object must have the same expiration date | |
|
||||
| DB - Table `segment_copies` | Ancestor_stream_id negative | If a segment with `stream_id = S` hasn't been copied, then the `segment_copies` table has no row having `ancestor_stream_id = S` | |
|
||||
| | Ancestor_stream_id positive | If a segment with `stream_id = S` has been copied, then the `segment_copies` table has at least one row having `ancestor_stream_id = S` | | | |
|
||||
| | Max copy references | If we already have `MaxCopyReferences` copies referencing a segment, then we should throw an error in this case. | |
|
||||
| | Original Segment - Deletion & stream_id check | If a copy `C` of original segment `S` is created, and then the original `S` gets deleted, then the segment copy `C` should become the original segment (does not appear in the `segment_copies` table anymore) | |
|
||||
| | Two Copies - ancestor_stream_id | If a new uploaded segment gets copied and then another copy is made from the original, then both copies should have the same ancestor_stream_id | |
|
||||
| | Two Copies - reference_counter | If a new uploaded segment gets copied and then another copy is made from the original, then the stream_id of the original should appear twice in the `segment_copies` table as `ancestor_stream_id` | |
|
||||
| | Two Copies - Original Segment Deletion (stream_id) | If a new uploaded segment gets copied and another copy is made from the original and then the original gets deleted, the first copied segment with the new ancestor stream id becomes the original segment | | | |
|
||||
| | Copy of Copy- ancestor_stream_id | If a new uploaded segment gets copied and another copy is made from that copy, then the first copy should have its ancestor_stream_id set as the original segments stream_id while the second copy should have its ancestor_stream_id set as the first copy's stream_id | |
|
||||
| | Copy of Copy- reference_counter | If a new uploaded segment gets copied and another copy is made from that copy, then in the reference_counter for the new uploaded segment and the first copy, the integer should be one (+1) | |
|
||||
| | Copy of Copy- Original Segment Deletion (stream_id) | When a new uploaded segment gets copied and another copy is made from that copy, after deleting the original, then the first copy should become the original segment while the second copy should have its ancestor_stream_id set as the first copy's stream_id | |
|
||||
| | Copy of Copy- First Copy Segment Deletion (stream_id) | When a new uploaded segment gets copied and another copy is made from that copy, after deleting the first copy, then the second copy should become the first and have its ancestor_stream_id set as the original's stream_id | | | |
|
||||
| | Copy of Copy- First Copy Segment Deletion (reference_counter) | If a new uploaded segment gets copied, another copy is made from that copy and then the first copy gets deleted, the reference counter of the other copied segment should be zero (0) and the original should be one (1) | |
|
||||
| Segment Size & Numbers | Bandwidth & Storage- inline segment | If a user uploads an inline segment and then server side copies from the source object to the destination object, then bandwidth and storage should stay the same before the operation | |
|
||||
| | File Size- inline segment | If a user uploads an inline segment and then server side copies from the source object to the destination object, then the destination object should contain total file size as the original source object | |
|
||||
| | Object Deleted During Copy- inline segment | If a user uploads an inline segment and then server side copies from the source object to the destination object all while deleting the original source object, then an error is thrown | |
|
||||
| | Object Deleted After Copy- inline segment | If a user uploads an inline segment, server side copies it from the source object to the destination object and then deletes the original source object, then an error is not shown | |
|
||||
| | Bandwidth & Storage- remote segment | If a user uploads an remote segment and then server side copies from the source object to the destination object, then bandwidth and storage should stay the same before the operation | |
|
||||
| | File Size- remote segment | If a user uploads an remote segment and then server side copies from the source object to the destination object, then the destination object should be the same size as the original source object | |
|
||||
| | Object Deleted During Copy- remote segment | If a user uploads an remote segment and then server side copies from the source object to the destination object all while deleting the original source object, then an error is thrown | |
|
||||
| | Object Deleted After Copy- remote segment | If a user uploads an remote segment, server side copies it from the source object to the destination object and then deletes the original source object, then an error is not shown | |
|
||||
| | <s>Copy 10000 Or More Parts</s> | <s>If a user uploads an object with 10000 parts or more and server side copies it from the source object to the destination object, it should be possible</s> | a limit of 10000 segments limits the number of parts to 10000 |
|
||||
| | Copy 10000 Or More Segments | If a user uploads an object with 10000 segments or more and server side copies it from the source object to the destination object, it should be possible | |
|
||||
| | <s>Copy Objects More than 5GB</s> | <s>If objects are more than 5GB in size, then upload-part-copy api must be used for server side copy</s> | There should be no limit on size of the object, the limit will only be on segment count. |
|
||||
| | <s>Copy Objects Less than 5GB<s/> | <s>If objects are less than 5GB in size, then server side copy must be an atomic operation</s> | There should be no limit on size of the object, the limit will only be on segment count. |
|
||||
| | Copy 0 bytes object | User should copy 0 bytes object without any error | |
|
||||
| | Copy inline segment | User should copy inline segment without any errors | |
|
||||
| | Copy remote segment | User should copy remote segment without any errors | |
|
||||
| | <s>Start server-side copying process and drop connection</s> | <s>File should be copied even when connection is dropped</s> | If the connection is dropped before FinishCopyObject is called, the object won't be copied |
|
||||
Loading…
Reference in New Issue
Block a user