[
https://issues.apache.org/jira/browse/HDFS-3680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13469591#comment-13469591
]
Marcelo Vanzin commented on HDFS-3680:
--------------------------------------
Hi Suresh, I think I addressed all your concerns (will upload new patch after
testing).
bq. what is the reason symlink is being done in logAuditEvent? Why is it a part
of this jira?
What do you mean "symlink is being done"? I'm not creating any symlinks. I'm
creating a FileStatus object based on an HdfsFileStatus, which is a private
audience class and thus cannot be used in the public audience AuditLogger.
bq. How does one add DefaultAuditLogger with a custom audit loggers? How does
isAuditEnabled() method work if you add an ability to setup DefaultAuditLogger?
I hope I addressed this in the new documentation. For your second question, you
should take a look at the "isDefaultAuditLogger" in FSNamesystem.java.
bq. FSNamesystem#auditLog should be moved to DefaultAuditLogger.
Since that field is public and used in other places, I'd rather not touch that.
bq. Should AuditLogger#logAuditEvent consider throwing IOException to indicate
error?
IOException would be one of many exceptions custom audit loggers could throw.
So I don't see why it should be special-cased here. My opinion is that audit
loggers in general shouldn't throw exceptions; if they really want to, having
to throw a RuntimeException indicates that it's not really an expected case.
bq. Sorry I have not caught up all the comments - what is the final decision on
how to handle logger errors? Currently the client gets an exception when
logAuditEvent fails. That does not seem to be correct.
I don't think there was an ultimate decision; my current patch follows the
"things work just like before" approach: currently, if the logging system
throws some kind of exception, it fails the request, just like the new code
does. If that's not desired, then it can be changed, but I think that's outside
the scope of this patch.
> Allows customized audit logging in HDFS FSNamesystem
> ----------------------------------------------------
>
> Key: HDFS-3680
> URL: https://issues.apache.org/jira/browse/HDFS-3680
> Project: Hadoop HDFS
> Issue Type: Improvement
> Components: name-node
> Affects Versions: 2.0.0-alpha
> Reporter: Marcelo Vanzin
> Assignee: Marcelo Vanzin
> Priority: Minor
> Attachments: accesslogger-v1.patch, accesslogger-v2.patch,
> hdfs-3680-v3.patch, hdfs-3680-v4.patch, hdfs-3680-v5.patch,
> hdfs-3680-v6.patch, hdfs-3680-v7.patch
>
>
> Currently, FSNamesystem writes audit logs to a logger; that makes it easy to
> get audit logs in some log file. But it makes it kinda tricky to store audit
> logs in any other way (let's say a database), because it would require the
> code to implement a log appender (and thus know what logging system is
> actually being used underneath the façade), and parse the textual log message
> generated by FSNamesystem.
> I'm attaching a patch that introduces a cleaner interface for this use case.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
