delta/openstack/python-swiftclient.git/tests/unit/test_shell.py, branch 3.4.0 opendev.org: openstack/python-swiftclient.git Allow for uploads from standard input. 2017-07-27T00:04:19+00:00 Timur Alperovich timuralp@swiftstack.com 2017-06-16T03:53:04+00:00 0982791db2ccb851f277ffa653065e4021e52b3f If "-" is passed in for the source, python-swiftclient will upload the object by reading the contents of the standard input. The object name option must be set, as well, and this cannot be used in conjunction with other files. This approach stores the entire contents as one object. A follow on patch will change this behavior to upload from standard input as SLO, unless the segment size is larger than the content size. Change-Id: I1a8be6377de06f702e0f336a5a593408ed49be02 
If "-" is passed in for the source, python-swiftclient will upload
the object by reading the contents of the standard input. The object
name option must be set, as well, and this cannot be used in
conjunction with other files.

This approach stores the entire contents as one object. A follow on
patch will change this behavior to upload from standard input as SLO,
unless the segment size is larger than the content size.

Change-Id: I1a8be6377de06f702e0f336a5a593408ed49be02
Buffer reads from disk 2017-07-12T00:04:49+00:00 Tim Burke tim.burke@gmail.com 2017-03-15T18:05:38+00:00 638d7c789cf3ccab61bf6af6fcab6e6d79b9e0a4 Otherwise, Python defaults to 8k reads which seems kinda terrible. Change-Id: I3160626e947083af487fd1c3cb0aa6a62646527b Closes-Bug: #1671621 
Otherwise, Python defaults to 8k reads which seems kinda terrible.

Change-Id: I3160626e947083af487fd1c3cb0aa6a62646527b
Closes-Bug: #1671621
Merge "Stop sending X-Static-Large-Object headers" 2017-06-14T23:35:32+00:00 Jenkins jenkins@review.openstack.org 2017-06-14T23:35:32+00:00 4515002d78c4ab28e65bcb52108f340d108708e1 






Merge "ISO 8601 timestamps for tempurl"
2017-05-18T14:37:17+00:00

Jenkins
jenkins@review.openstack.org

2017-05-18T14:37:17+00:00

6d5e87a1830977d3962e5cf22476b0892b39ce81












respect bulk delete page size and fix logic error
2017-04-20T16:41:53+00:00

John Dickinson
me@not.mn

2017-04-04T22:20:30+00:00

0cc4d8af18157000d4d5d1205700d6494c5935ce

Previously, using SwiftService to delete "many" objects would use
bulk delete if available, but it would not respect the bulk delete
page size. If the number of objects to delete exceeded the bulk delete
page size, SwiftService would ignore the error and nothing would be
deleted.

This patch changes _should_bulk_delete() to be _bulk_delete_page_size();
instead of returning a simple True/False, it returns the page size for
the bulk deleter, or 1 if objects should be deleted one at a time.
Delete SDK calls are then spread across multiple bulk DELETEs if the
requested number of objects to delete exceeds the returned page size.

Fixed the logic in _should_bulk_delete() so that if the object list
is exactly 2x the thread count, it will not bulk delete. This is the
natural conclusion following the logic that existed previously: if
the delete request can be satisfied by every worker thread doing one
or two tasks, don't bulk delete. But if it requires a worker thread
to do three or more tasks, do a bulk delete instead. Previously, the
logic would mean that if every worker thread did exactly two tasks, it
would bulk delete. This patch changes a "<" to a "<=".

Closes-Bug: 1679851
Change-Id: I3c18f89bac1170dc62187114ef06dbe721afcc2e





Previously, using SwiftService to delete "many" objects would use
bulk delete if available, but it would not respect the bulk delete
page size. If the number of objects to delete exceeded the bulk delete
page size, SwiftService would ignore the error and nothing would be
deleted.

This patch changes _should_bulk_delete() to be _bulk_delete_page_size();
instead of returning a simple True/False, it returns the page size for
the bulk deleter, or 1 if objects should be deleted one at a time.
Delete SDK calls are then spread across multiple bulk DELETEs if the
requested number of objects to delete exceeds the returned page size.

Fixed the logic in _should_bulk_delete() so that if the object list
is exactly 2x the thread count, it will not bulk delete. This is the
natural conclusion following the logic that existed previously: if
the delete request can be satisfied by every worker thread doing one
or two tasks, don't bulk delete. But if it requires a worker thread
to do three or more tasks, do a bulk delete instead. Previously, the
logic would mean that if every worker thread did exactly two tasks, it
would bulk delete. This patch changes a "<" to a "<=".

Closes-Bug: 1679851
Change-Id: I3c18f89bac1170dc62187114ef06dbe721afcc2e







Stop sending X-Static-Large-Object headers
2017-04-10T22:40:35+00:00

Tim Burke
tim.burke@gmail.com

2017-04-10T22:38:58+00:00

aaaed55cd46902612f1ba93ac3394cfd99679b00

If we were to include this in a normal PUT, it would 400, but only if
slo is actually in the pipeline. If it's *not*, we'll create a normal
Swift object and the header sticks.

- This is really confusing for users; see the related bug.
- If slo is later enabled in the cluster, Swift starts responding 500
  with a KeyError because the client and on-disk formats don't match!

Change-Id: I1d80c76af02f2ca847123349224ddc36d2a6996b
Related-Change: I986c1656658f874172860469624118cc63bff9bc
Related-Bug: #1680083





If we were to include this in a normal PUT, it would 400, but only if
slo is actually in the pipeline. If it's *not*, we'll create a normal
Swift object and the header sticks.

- This is really confusing for users; see the related bug.
- If slo is later enabled in the cluster, Swift starts responding 500
  with a KeyError because the client and on-disk formats don't match!

Change-Id: I1d80c76af02f2ca847123349224ddc36d2a6996b
Related-Change: I986c1656658f874172860469624118cc63bff9bc
Related-Bug: #1680083







ISO 8601 timestamps for tempurl
2017-03-29T18:27:39+00:00

Christopher Bartz
bartz@dkrz.de

2017-01-20T17:04:31+00:00

8e08931b9ffd872a2b5537149a5d3b9f3e9bb5d4

Client-side implementation for ISO 8601 timestamp
support of tempurl middleware. Please see

https://review.openstack.org/#/c/422679/

Change-Id: I76da28b48948475ec1bae5258e0b39a316553fb7





Client-side implementation for ISO 8601 timestamp
support of tempurl middleware. Please see

https://review.openstack.org/#/c/422679/

Change-Id: I76da28b48948475ec1bae5258e0b39a316553fb7







prefix-based tempurls support
2017-01-19T15:34:26+00:00

Christopher Bartz
bartz@dkrz.de

2016-12-08T12:42:35+00:00

3934bd606acc2333ee9ae63a40baa35928ef908d

Implements client-side functionality for
prefix-based tempurls.

Please see: https://review.openstack.org/#/c/274048/

Change-Id: I8d7701daee888ed1120271a96c0660b01543ca2d





Implements client-side functionality for
prefix-based tempurls.

Please see: https://review.openstack.org/#/c/274048/

Change-Id: I8d7701daee888ed1120271a96c0660b01543ca2d







Merge "modify 'swift <sub_command> —help' display"
2016-12-13T23:00:01+00:00

Jenkins
jenkins@review.openstack.org

2016-12-13T23:00:01+00:00

39a0eda48666e88fea3ba2109773dbadaa2d5474












modify 'swift <sub_command> —help' display
2016-12-13T13:41:08+00:00

Shashirekha Gundur
shashirekha.j.gundur@intel.com

2016-10-23T19:59:11+00:00

41666d60c88e4b70bceb7898459a93e6cf389382

In python swiftclient:  swift <sub_command> —help will now
display st_<sub_command>_options + st_<sub_command>_help texts
e.g. http://paste.openstack.org/show/589752/

Change-Id: I34e4b2ac29ef395f8ca474ce7a82f59a1fd8c7f4
Closes-Bug: #1621415





In python swiftclient:  swift <sub_command> —help will now
display st_<sub_command>_options + st_<sub_command>_help texts
e.g. http://paste.openstack.org/show/589752/

Change-Id: I34e4b2ac29ef395f8ca474ce7a82f59a1fd8c7f4
Closes-Bug: #1621415