Gargi-jais11 commented on code in PR #11242:
URL: https://github.com/apache/ozone/pull/11242#discussion_r4068599655
##########
hadoop-ozone/s3gateway/src/main/java/org/apache/hadoop/ozone/s3/endpoint/ObjectAttributesHandler.java:
##########
@@ -204,8 +214,10 @@ private GetObjectAttributesResponse buildResponse(String
keyPath, OzoneKey key,
if (eTag != null) {
String partsCountStr = extractPartsCount(eTag);
if (partsCountStr != null && completedPartSizes != null) {
+ boolean directoryBucketLayout =
+ context.getBucket().getBucketLayout().isFileSystemOptimized();
Review Comment:
@ArafatKhan2198 and @rich7420 I agree that for FSO GetObjectAttributes we
need the bucket layout (FSO vs general-purpose) to decide whether to return
per-part <Part> elements. S3G already calls OM once via getKeyInfo for
ObjectParts; using getBucket() adds a second OM call and can require bucket
READ even when the caller only has key READ.
OM already resolves layout in that same **getKeyInfo path
(ResolvedBucket)**, but it is not returned to the client today. Adding optional
bucketLayout on `GetKeyInfoResponse` exposes data OM already loaded and wil
have no extra RPC and no change to key ACL scope.
I want to get ur opinion - putting bucketLayout on **OmKeyInfoResponse**
would it be wrong ? A field on the get-key response is the appropriate place
for this read-time context.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
