952f50e6e3
testplan: Adding a testplan for Server Side Copy This is a testplan for Server Side Copy that follows the testplan template.
15 KiB
15 KiB
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 | ||
| 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 | ||
| 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 | ||
| There should be no limit on size of the object, the limit will only be on segment count. | |||
| 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 | ||
| If the connection is dropped before FinishCopyObject is called, the object won't be copied |