[
https://issues.apache.org/jira/browse/ACE-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13231137#comment-13231137
]
Bram de Kruijff commented on ACE-230:
-------------------------------------
Just some thoughts..I think there are two valid use cases that should both be
covered.
First the "development & cleanup case" where I just want to purge a target,
meaning that all records are disposed of. This is what I created ACE-167 for as
I think this is the logical consequence of a DELETE on the REST api. There
should be no difference between deleting an artifact, feature, distribution or
target. Note however this solution is under the implicit assumption that a log
is not a first class citizen of the domain itself. If it is (or can be) another
valid approach id supporting CRUD on logs. My use case would then be covered by
deleting both the target and it's associated log separately.
Second the "production & retention case" where a target may be logically
gone/removed but the logs should be kept for historical reasons. This is what
effectively happens now (somewhat). However, these targets should probably not
appear (by default) in the UI. An approach could be just to add same kind of
ARCHIVED state? In addition I believe they should not block or magically
reappear when a new target with the same name is created. Right now I think a
target only has one "identifier" which is also used in the ui. A solution could
be to generate unqiue identifier (on POST through the REST api) and allow for
logical names
Thinking about it, as we also want to be able to access logs through the REST
api, I think making logs a separate entity may not be such a strange idea. Not
sure how difficult is will be though :)
> Avoid removed targets to be resurrected by their audit log.
> -----------------------------------------------------------
>
> Key: ACE-230
> URL: https://issues.apache.org/jira/browse/ACE-230
> Project: ACE
> Issue Type: New Feature
> Reporter: J.W. Janssen
>
> The basic fix for ACE-167 allows targets to be removed. However, when there's
> an audit log present for a target, it will cause the target to be resurrected
> upon synchronization of the logs. This is not desired. Either the audit log
> for a target should be purged, or during the audit log synchronization it
> should detect somehow that a target is removed, thereby avoiding it to be
> resurrected.
> There are several possibilities for fixing this:
> * purge the entire audit log at the server; when the target is no longer
> running, the audit log will be recreated for the remaining targets. This
> won't work if the target is still running (which is rather exotic in this
> situation), or if there are relay server(s) present to which the removed
> target once talked. These relay(s) do not have a notion that the target is
> removed, thus will happily sent their audit logs to the main server,
> including the one for the removed target. For development situations, this
> might not be an issue as there are probably no relays involved;
> * add a deleted timestamp attribute to the target object, and not really
> remove it from the repository. This timestamp will be used during the
> synchronization process to determine whether there are *new* events that
> should cause the target to be resurrected. If there are no newer events
> (i.e., the event timestamp > deleted timestamp), the target will not be
> recreated. The only thing is that removed targets still remain in the
> repository, thus need to be hidden in the UI;
> * make the audit log merge process smarted, for example, by only merging
> audit logs for targets seen in the last N seconds. In combination with a
> purge of the entire audit log at the server and some patience, it would
> prevent a removed target to be resurrected.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
