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 ___________________________________________ 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 Sheffield 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 InMemoryEntityAuditRepository. 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 correct Nigel.
