Project

General

Profile

Actions

User story #3029

closed

User story #3002: Allow to rollback to a previous configuration policy from the event log screen

Add back-end necessary information to link event-log to Git commits

Added by François ARMAND over 11 years ago. Updated almost 9 years ago.

Status:
Released
Priority:
2
Category:
Architecture - Code maintenance
Target version:
UX impact:
Suggestion strength:
User visibility:
Effort required:
Name check:
Fix check:
Regression:

Description

To be able to give the user the possibility to roll back to a given event log (actually, to the state just before or after the modification), we need to be able to link event logs and git commits.

What we want is some kind of service that given an event log ID is able to retrieve the corresponding Git Commit ID, if such a commit exists (it is not mandatory, even if there is no errors).

Pull request : https://github.com/Normation/rudder/pull/59

Actions #1

Updated by François ARMAND over 11 years ago

I can see several workflows for save in LDAP/log event storage/git storage, and none seems clearly superior to the other or to provide the awaited behavior.

For now, when we modify an object, that is what is done - an be aware that an error to any step stop the whole thing, leading to an error :

  • 1. get context (current state, parents, etc) and sanity/prerequisite check (name availability, etc)
  • 2. update the object and get the diff - that's atomic, and that's the only atomic part
  • 3. log the event modification
  • 4. if auto-archive is requested, autoarchive.

2. and 3. are so close because we really want to log as soon as the modification is done, to minimize the inconsistency window. Actually, these two steps should be atomic, but we technically can't do that.

The problem is that we want to latter know what happened on step 4 (the commit ID) to be available for step 3 (the log event).

So there is basically 3 ways to achieve that:

  • 1. put step 3 in place of step 4, so that the commit ID is available in the event log
  • 2. add a step 5 that will update some database saying "commit ID from step 4 is related to event log id from step 3". That database can be :
    • the log event table (a new column);
    • an other database or table, dedicated to store that relationship.
  • 3. have a common, pre existing information shared by step 3 and step 4, so that we know that these steps are consequences of the pre-existing information.

1. and 2. above share fundamental problems:

  • the solution is not extensible. If tomorrow, we want to add an other post-modification action, we will have to (again) find a way to order steps for technical reason or (again) add some column in the event log table.
  • they brings false (technical) dependencies so that we don't know any more what is functional requirement and technical one: git storage is not really dependant from the event log, nor the other way around. But we want to store the fact that the two are related to the acceptance of a modification.

So it seems to means that we want to be able to uniquely identify each modification, and then create map between consumers of these modification.

Consumers may be the LDAP store, the log event repository, the git repos, etc.

These UUID would be specific to a given Rudder installation, and are meaningless outward that installation bounds. Typically, there is no meaning for such an UUID in the API to request a Rule modification (but the UUID can be returned by the successful request, and used to look-up what was the modification with that UUID).

Moreover, it seems to be the natural solution toward we are going with modification worflows.

Technical details

Having a "modification UUID" mean that:

  • we want to generate that UUID at some step. Today, it seems to make sense to generate the UUID when the modification is commited, at the same time as the Diff. Tomorrow, we will certainly want to have modification (diff) existing before any actual modification in repository.
  • we have to store that UUID in the log event table, either in a dedicated column, or as part of the detail modification. It seems to make sense to have that in the details as it's a part of the modification itself, but there is also great cons:
    • performance wise, it will be horrible to look-up on that, so if we want to find all logs related to a given modification, that will be slow (and it seems to be an acceptable use case) ;
    • it also make sense to consider the details (the XML part) as a common, generic part between what is part of a modification request from the outside, and the internal Rudder representation (with an UUID) of such request.
  • we want to store the link between a commit id and the modification UUID
Actions #2

Updated by François ARMAND over 11 years ago

  • Target version set to 24
Actions #3

Updated by François ARMAND over 11 years ago

  • Category set to Architecture - Code maintenance
  • Status changed from New to In progress
  • Assignee set to François ARMAND

The first step is to add some kind of UUID to follow a modification across several events or subtasks.
Then, we will be able to use that information to collect back all these linked events and navigate to the interesting one for us.

Actions #4

Updated by Vincent MEMBRÉ about 11 years ago

  • Description updated (diff)
  • Status changed from In progress to 10
  • Assignee changed from François ARMAND to Jonathan CLARKE
  • Priority changed from N/A to 2
  • Target version changed from 24 to 2.5.0~beta1

Functionnal reviex has been made,

So it can be changed to Technical review, pull request done : https://github.com/Normation/rudder/pull/59

Actions #5

Updated by Jonathan CLARKE about 11 years ago

  • Status changed from 10 to Pending technical review
Actions #6

Updated by François ARMAND about 11 years ago

  • Status changed from Pending technical review to 12
  • Assignee changed from Jonathan CLARKE to François ARMAND
Actions #7

Updated by Vincent MEMBRÉ about 11 years ago

  • Status changed from 12 to Pending release
  • % Done changed from 0 to 100
Actions #8

Updated by Matthieu CERDA about 11 years ago

  • Status changed from Pending release to Released
Actions #9

Updated by Benoît PECCATTE almost 9 years ago

  • Tracker changed from Enhancement to User story
Actions

Also available in: Atom PDF