Rudder

We had a case where starting two rollback at a couple second appart led to the erasing of system group and technique - actually not lost, but hidden for one who doesn't know where to look at.

So, the problem is that we use LDAP (which doesn't have transaction) and that a rollback proceeds like that:

1/ move current group and technique root into ou=Archives, ou=Rudder, cn=rudder-configuration
2/ restore Git archive corresponding to rollback point, which recreate group/technique, but without system elements
3/ copy from archie system elements
4/ delete archive

Here, a second rollback was started during 2 and before 3. So what was copied in archive that time was missing system elements, as seen here:

This also likely broke first rollback, which wasn't able to complete. Second rollback continues, but then, it can't restore system elements, since they are missing, and it fails, too. And we end up without system techniques in the awaited place (but nothing lost).

A first not too hard correction would be to put rollback queries in a queue so that they don't interfer from one other to each other. This is stil rather barok and won't prevent cases were other ldap op breaks expectation during the process, but it will avoid that horror case.

A real solution would be to just commit back entries corresponding to whatever action is rollback, and only that, in a new apeend-only modification, so that nothing is lost. It could be done with a bit of hand waving and a git checkout commitId -- only-modified-files.xml && git commit && restore archive from last git.
It could even be better to read entries that were modified, get back their value from git at that point, materialize them in code and save them back.
That second change is massive in semantic evolution of rollback, and need a major version of rudder.