Hello Nigel,
This makes a lot of sense to me. 

Does the Audit log interface assume a transactional backing store -so that 
data updates and the audit log entry are committed in the same 
transaction?   If not then we might also want to consider a simple file 
based audit log as the entry level service.

I am assuming each of the audit log implementations implement the same 
Java interface?  So it also makes sense to move this interface - and the 
audit log management to the GAF. 

I added a getAuditLog method to the connector interface to allow an 
application to create an audit trail for their use of a connector - this 
could also be used by the gaf plugins.  I was also assuming that this was 
something we need to synch up with between the GAF and the OCF since the 
OCF should really get its audit logs from the GAF.

All the best
Mandy Chessell CBE FREng CEng FBCS
IBM Distinguished Engineer

Master Inventor
Member of the IBM Academy of Technology
Visiting Professor, Department of Computer Science, University of 

Email: mandy_chess...@uk.ibm.com
LinkedIn: http://www.linkedin.com/pub/mandy-chessell/22/897/a49

Assistant: Janet Brooks - jsbrook...@uk.ibm.com

From:   Nigel Jones <jon...@uk.ibm.com>
To:     d...@atlas.incubator.apache.org
Date:   24/07/2017 13:40
Subject:        Audit Repository: Hbase, No-op ....

I was just reading ATLAS-1870 which related to default audit 
repositories. I see the default is HBaseBasedAuditRepository, and that 
there is also NoopEntityAuditRepository, and 

I'm thinking that when Atlas is used in a non-hadoop oriented 
environment it would be useful to have a non-hbase, persistent (helps a 
little with compliance ;-) ) audit respository. Perhaps another RDB, or 
indeed in solr/elastic search alongside Ranger's audit events.

I'll raise a JIRA on this if it's felt useful & my understanding is 


Reply via email to