[
https://issues.apache.org/jira/browse/HDFS-6326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13990882#comment-13990882
]
Daryn Sharp commented on HDFS-6326:
-----------------------------------
Catching all exceptions bothers me a bit that if the call fails for other
transient errors, that acls are assumed to not be supported. Maybe it doesn't
seem like a big deal today because it's "only" for one command, but it will be
if I ever get around to adding readline support to FsShell...
It's probably more appropriate for WebHdfsFileSystem to detect if acls are
supported upon the first call. It keeps the ugliness out of FsShell. It would
be great to also push the hdfs-specific exception handling into
DistributedFileSystem.
Given that we now have extensible protobufs and json, is there any reason why
FileStatus, or FSPermission, etc don't return a boolean if there's an acl on
the file? Then an acl call is may only be made when necessary. The
performance impact of doubling the rpc/webhdfs calls for ls concerns me,
especially for recursive ls on a large directory, when acls are likely to be
the exception rather than the common case.
> WebHdfs ACL compatibility is broken
> -----------------------------------
>
> Key: HDFS-6326
> URL: https://issues.apache.org/jira/browse/HDFS-6326
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: webhdfs
> Affects Versions: 3.0.0, 2.4.0
> Reporter: Daryn Sharp
> Assignee: Chris Nauroth
> Priority: Blocker
> Attachments: HDFS-6326.1.patch, HDFS-6326.2.patch
>
>
> 2.4 ACL support is completely incompatible with <2.4 webhdfs servers. The NN
> throws an {{IllegalArgumentException}} exception.
> {code}
> hadoop fs -ls webhdfs://nn/
> Found 21 items
> ls: Invalid value for webhdfs parameter "op": No enum constant
> org.apache.hadoop.hdfs.web.resources.GetOpParam.Op.GETACLSTATUS
> [... 20 more times...]
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
