Red Hat Bugzilla – Bug 998980
[RFE] Logging for user changes
Last modified: 2016-02-10 14:23:24 EST
This RFE raised from bug 997402
Description of problem:
Please add functionality which would be capable of logging user changes in RHEVM.
Examples of user change:
VM (moving from HA to non HA), changing RAM size, changing QoS policy, etc.
For customers it is important to be able to keep track of what was changed, how it was changed and when it happened.
Martin - any change done by a user today is supposed to be audited. iiuc, the gap you are missing is on what actually changed in edit commands (specifically for a VM edit command?)
(In reply to Itamar Heim from comment #1)
> Martin - any change done by a user today is supposed to be audited. iiuc,
> the gap you are missing is on what actually changed in edit commands
> (specifically for a VM edit command?)
yes, I came over it when editing QoS, if I will change for example bandwidth for network inbound traffic, the log will just record that there was an update of QoS, if I do 5 such changes over period of time, and than receive complaint from user/s that connection of their VMs is causing trouble, I will have no chance to know what was changed when and how, therefore my job to mitigate this problem will be more complicated
setting to infra to try and handle this in a generic manner.
i have some recollection of an ObjectIdeneityChecker or something like that for comparing fields and checking which were changed which may be relevant.
There are two ways of solving this issue. First one is nice generic way for all the update commands which would require to change command inheritance hierarchy. There is no common base for update commands. All the commands inherit directly or indirectly from VdsCommand. By having this update common abstraction we could introduce generic behavior across them. As short term solution we can change AuditLogableBase to introduce logupdate which will add object delta to the message. For each update command we can override logCommand method and provide object delta using ObjectIdeneityChecker.
I think the right place to handle this, using entities making sense to use is at the REST API level, once it becomes the entrypoint for the GUI. so we should revisit this one later on.