smengcl commented on code in PR #4188:
URL: https://github.com/apache/ozone/pull/4188#discussion_r1550044937
##########
hadoop-ozone/client/src/main/java/org/apache/hadoop/ozone/client/rpc/RpcClient.java:
##########
@@ -1195,7 +1196,8 @@ public OzoneOutputStream createKey(
.setReplicationConfig(replicationConfig)
.addAllMetadata(metadata)
.setAcls(getAclList())
- .setLatestVersionLocation(getLatestVersionLocation);
+ .setLatestVersionLocation(getLatestVersionLocation)
+ .setOwnerName(ownerName);
Review Comment:
Actually I wonder if we really need to add this owner field to every single
new key created in Ozone.
Arguably we could just leave this as unset (empty) to indicate the default
behavior, which is to inherit parent's owner. This way we don't bloat every
single key with this extra owner string in its proto message.
Cons of setting `owner` for every single new key:
1. Slight perf hit for every new key/dir creation.
2. This also implies `chown` on a bucket/dir would be recursive by default.
Makes `chown` much slower. (Where in the case of not setting `owner` for every
key, we don't need to recurse by default because the sub-keys and sub-dirs
should just inherit the parent owner)
4. When a cluster is upgraded to a new Ozone version with key ownership
support, all existing keys would natually have empty owners as well. Unless we
add a lengthy step during OM upgrade to add owner to all existing keys, which I
don't think is the best idea).
Pro:
1. On the other hand I get that the the owner field in key info is required
for "sticky bit" behavior to work with properly Ranger authorizer (previously
there is a workaround, HDDS-9701).
--
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]
