Coverage increased (+0.06%) to 78.681% when pulling b0d9caa on kayrus:swift-bulk-delete into 65804fe on gophercloud:master.

Build succeeded.

• gophercloud-unittest : SUCCESS in 2m 34s
• gophercloud-acceptance-test : SUCCESS in 1h 36m 43s
• gophercloud-acceptance-test-ironic : SUCCESS in 31m 49s

@jtopjian ready for review

We should be able to easily add an acceptance test for this, right? Let me know if you need help.

@jtopjian just noticed that bulk-delete is also valid for containers. It would be great if you help me with acceptance tests.

Build failed.

• gophercloud-unittest : SUCCESS in 3m 11s
• gophercloud-acceptance-test : FAILURE in 2h 10m 16s
• gophercloud-acceptance-test-ironic : SUCCESS in 31m 12s

Build succeeded.

• gophercloud-unittest : SUCCESS in 3m 23s
• gophercloud-acceptance-test : SUCCESS in 1h 40m 20s
• gophercloud-acceptance-test-ironic : SUCCESS in 34m 04s

According to https://github.com/openstack/swift/blob/a495f1e327fac17246a296721fb1eda8470e4773/swift/common/middleware/bulk.py#L156..L194, bulk delete should have a Content-Type: text/plain header and contain a body with filenames separated by a newline.

bulk delete should have a Content-Type: text/plain header and contain a body with filenames separated by a newline.

Right. Now I recall that I looked into this in the past and silently backed away 🙂

This means that we'll need to modify UpdateOpts and DeleteOpts for both containers and objects to include an option for a body, and then pass that body in the actual Update and Delete calls.

In addition, an actual structured response body is sent back, which differs from a normal Swift response where the bulk of the info is in the headers: https://docs.openstack.org/ocata/user-guide/cli-swift-bulk-delete.html

In my opinion, a better approach might be to make entirely new functions/actions called BulkDelete with their own BulkDeleteOpts. I believe Swift treats POST and DELETE equally, so let's just standardize on using POST (including a body with a DELETE call feels wrong).

BulkDeleteOpts can have a Containers or Objects field of type []string where the user can specify the list of containers/objects to be bulk deleted. in the To<Container/Object>BulkDeleteQuery method, we can return a plaintext string of []string joined by a newline, so that it can be passed to the client.Post method.

Finally, I think a 409 response (I think this means that only some of the requested containers/objects were deleted) might be a little common and we should either consider treating it as valid response code... but I'm not 100% sure on this, yet.

Thoughts?

@jtopjian no concerns, though at first glance it looked like a low hanging fruit.

Build succeeded.

• gophercloud-unittest : SUCCESS in 3m 05s
• gophercloud-acceptance-test : SUCCESS in 1h 45m 50s
• gophercloud-acceptance-test-ironic : SUCCESS in 31m 52s

@jtopjian I reworked the PR. I also discovered and fixed redundant pointers usage and unencoded container/object names.

@jtopjian can you add a release note that container and object names are now urlencoded?

Sure - but we should try to have things like this in separate PRs.