timuralp commented on this pull request.
> + * @param metadata
+ * corresponds to {@link SwiftObject#getMetadata()}.
+ * @param headers
+ * Binds the map to headers, without prefixing/escaping the header
+ * name/key.
+ *
+ * @return {@link SwiftObject#getEtag()} of the object, which is the MD5
+ * checksum of the concatenated ETag values of the {@code segments}.
+ */
+ @Deprecated
+ @Named("dynamicLargeObject:replaceManifest")
+ @PUT
+ @ResponseParser(ETagHeader.class)
+ @Headers(keys = "X-Object-Manifest", values =
"{containerName}/{objectName}/")
+ String replaceManifest(@PathParam("objectName") String objectName,
+ @BinderParam(BindToJsonPayload.class) Collection<Segment> segments,
Swift does not return the DLO ETag as a response to PUT. At least I do not
observe this with docker-swift and Swift 2.14 (latest release):
```
DEBUG:swiftclient:REQ: curl -i
http://localhost:32768/v1/AUTH_test/test/s3proxy.jar -X PUT -H
"x-object-meta-mtime: 1440388916.150022" -H "Content-Length: 0" -H
"x-object-manifest:
test_segments/s3proxy.jar/1440388916.150022/7663104/1000000/" -H "Content-Type:
" -H "X-Auth-Token: AUTH_tkadf8c03346214185ba387e3888893305"
DEBUG:swiftclient:RESP STATUS: 201 Created
DEBUG:swiftclient:RESP HEADERS: {u'Content-Length': u'0', u'Last-Modified':
u'Tue, 06 Jun 2017 06:09:31 GMT', u'Etag': u'd41d8cd98f00b204e9800998ecf8427e',
u'X-Trans-Id': u'tx9825d3a9fadb4c50bf4f8-005936471a', u'Date': u'Tue, 06 Jun
2017 06:09:30 GMT', u'Content-Type': u'text/html; charset=UTF-8',
u'X-Openstack-Request-Id': u'tx9825d3a9fadb4c50bf4f8-005936471a'}
```
The ETag above is of the empty string and jclouds should expose exactly that as
a response to a putManifest request.
In jclouds 1.9, the interaction you're describing is the end of performing an
MPU where a 0-sized DLO manifest is uploaded (0-sized object with the
X-Object-Manifest header). The two methods that are implemented are for the
case of specifying manifest metadata through an existing Blob or through the
object name. I don't think jclouds 2.0 should replicate either of the
approaches.
In jclouds 2.0, you could introduce two DLO methods, akin to the SLO setup,
where one has only the metadata parameter
(```@BinderParam(BindObjectMetadataToHeaders.class) Map<String, String>
metadata```), while the other one includes a headers parameter
(```@BinderParam(BindToHeaders.class) Map<String, String> headers```). That
would be inline with the current code.
We should not attempt to satisfy old clients, as the prior API has been marked
deprecated and jclouds should prefer to use SLO whenever possible. DLO is an
option only for clients who explicitly have to use it to interact with old data
or if they have some other special reason.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1105#discussion_r120275386
