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
Member of the IBM Academy of Technology
Visiting Professor, Department of Computer Science, University of
Assistant: Janet Brooks - jsbrook...@uk.ibm.com
From: Nigel Jones <jon...@uk.ibm.com>
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