My favorites | Sign in
Project Home Downloads Wiki Issues Source
New issue   Search
for
  Advanced search   Search tips   Subscriptions
Issue 2020: All hook processing stops - but Gerrit keeps working fine otherwise - implement better handling of dead hook subsystem
3 people starred this issue and may be notified of changes. Back to list
Status:  New
Owner:  ----


Sign in to add a comment
 
Reported by casta...@motorola.com, Jul 18, 2013
We recently uncovered a problem whereby the backend hook process substructure of Gerrit appears to just stop/die/end whatever.

Apparently the Gerrit architecture (we are using 2.4.4 as of this writing) is designed in such a way as to permit the continuation of all Gerrit behavior even though the backend hook processing stops.

This seems to me like a risky implementation.

Backend hook processing - particularly in the patchset-created and comment-added and ref-updated hooks - is used by us (and I would guess by many) to implement interfaces to other systems that help control Gerrit workflow.  The most notable example is integration with a change management system that keeps accounting straight between what is in Git and Gerrit and what is in the CM system.

When hook processing fails like this it has lead to data inconsistencies between Gerrit/Git and our other systems.  This condition effectively allows users to bypass company policy (which is implemented in hooks) and execute changes they should not be be allowed to execute.

The suggested feature is three fold:

1) If possible recover from a dead hook subsystem.
2) If not possible then provide a notification mechanism to notify users in the "Administrators" group whenever a critical error like this has occurred.
3) Provide an option that administrators can set that will block commits or reference updates PRE-OPERATION when the server is in a critical state and cannot process hooks.  (Pre-operation is necessary to ensure remotes stay in sync with the server's copy of changes.)   Alternatively, don't make this an option.  Make it default behavior.


With these changes in place administrators can be notified when a critical fault has occurred, the system will prevent itself from being corrupted with data out of sync with remotes, and the environment in which Gerrit is deployed and integrated via hooks can be kept clean and uncorrupted when faults occur of this nature.

 




Jul 11, 2014
#1 nethors...@gmail.com
Yes, We also meet this problem, bring us trouble to our jobs.
Gerrit: 2.8.4

Is there any solution? 
Sign in to add a comment

Powered by Google Project Hosting