Question #2623
closed
How to get data from all modify events ?
Description
When handling data from modify event, information are missing : we only have modification information but not the all data on the object. For exemple, if we change a Rule's name, we'll only have as data the old and the new name, but not information like serial, target or description on that rule. Those missing information need to be display in the Event logs.
To do so, we have to modify the data format serialisation to add the missing data.
But with that solution, we need to handle the old event with the old format which are stocked in the database.
In the case that we decide to change the format we have 3 solutions :
1° We support the old format. Old events logs will have less information in the UI.
2° We could update the old events in the database which need lot of work. Because we need to update every old events log with the new metadata. A migration script would be necessary.
3° We could make a request when the data are missing to get the state of data at that date.
We have more interest in 1° which is the easier to put in place. But some users would prefer the 2°, which is harder to put in place.
What do you think ?
Updated by François ARMAND over 12 years ago
I'm not really sure we want to display all information of each item in each event log.
Or at least, I'm almost sure we don't want to store that much information in a so unscalable way in our poor database that is not at all relationnaly used here.
If we really want to have each revision of each group/directive/rules available forever, we don't have the good backend, and we should just go and buy a datomic licence - just kidding, but you get the idea: we want a event sourcing system, with fully immutable data, and a efficient diff storing scheme. I'm not aware of any open source, embedable datastore with such properties.
If we just want to always display name, that's possible and even has it's how ticket : name are already historized for reporting, so we just have to query for the one used at the given time.
So, my feelings are:
- for 2.5, just add name in event log, not the full versionned item;
- if we collectivelly believe that it is a need to have all these things available, we will have to think a little bit more of the datastorage model, with actual numbers to support architecture choice. But clearly, it's a big change.
For the record, you "2" proposition already exists for 2.3 => 2.4 migration, so we certainly could implement something alike for a 2.4 => 2.5 event log update, see rudder-core/src/main/scala/com/normation/rudder/migration.EventLogsMigration_10_2.scala.
Well, it is not a simple task (very error prone), but at least, we have a model for it now.
Updated by Vincent MEMBRÉ over 12 years ago
I think we don't have time to change the structure of "modify" event logs before the 2.5 release.
At least we could make a better looking report with only the changes done.
Updated by Jonathan CLARKE over 12 years ago
- Target version changed from 50 to 2.4.0~beta3
Updated by Nicolas PERRON over 12 years ago
- Target version changed from 2.4.0~beta3 to 2.4.0~beta4
Vincent MEMBRÉ wrote:
I think we don't have time to change the structure of "modify" event logs before the 2.5 release.
At least we could make a better looking report with only the changes done.
I bet you were talking about 2.4, isn't it ?
I wonder if any work has been done about it ? Vincent was working on event log.
At least, this is not a blocking issue so I change it to the next run.
Updated by Vincent MEMBRÉ over 12 years ago
Yeah sure i was talking about 2.4 indeed, my finger slipped ;)
I think, we don't want to modify event log further in 2.4, that ticket can be rejected/closed
Updated by Nicolas PERRON over 12 years ago
- Status changed from Discussion to Released
Ok, so I close this bug, as no work was needed.