some notes of Martin's report of Gerrit Hackathon #3, May 7-11 2012
which giving you some insights into the progress and also into some of
the plans for future Gerrit directions.
the 3rd Gerrit Hackathon focus on adding a plugin framework, in a few
beginnings of a solid plugin infrastructure now in place.
Plugin concepts have 2 main types:
-plugins with full access to Gerrit’s internals (and bound to a
specific Gerrit version),
-extensions which would only be bound to light stable interfaces.
Plugins and extensions both got their own classloaders, but extensions
were isolated from gerrit classes.
Two jar files are created to compile plugins and extensions against.
The plugin jar is one massive jar with Gerrit and all its dependencies
This large jar file should make it possible for plugin devs
to create plugins quickly without having to download the
many dependencies independently using maven.
The extensions jar file consists mainly of the new fairly sparse top
initial plugin infrastructure
-Plugins own Guice injectors.
-httpServlet plugin support in Gerrit.
-adapted pegdown so that it could be used by plugin developers to
create lightweight documentation for their plugins.
-a plugin command to be able to operate on and view plugins in a live
rework of the Gerrit core:
-refactored the replication as plug-in
-introduced the ability to create aliases in order to use plugins
commands as surrogates of existing commands.
-added the ability to capture JSON/RPC and SSH actions generate audit-
-the ability to add extra custom commit validation through plugins.
another interesting items:
a very generic event extension mechanism to be used by more than just
“approval” extensions. This led to much
infrastructure being built, but there is still work to be done to make
this fully configurable the way intended.
discuss old changes under review:
add support for change labels:
we did not want to add this additional data to the database since we
are attempting to migrate away from the db.
To put this data into git notes, it will be necessary to have an
Shawn decreed that this would need to be done (or attempted) with
Lucene. This could then pave the path for greater use of Lucene in
Gerrit. It is
recognized though that Lucene may need some work to operate smoothly
with minor frequent updates to metadata.
get Junio's approval to propose non backwards compatible changes to
the git protocol to make our use cases
more efficient. Shawn also supported breaking the git protocol and
suggested to only send refs/heads/ and capabilities in the initial
server response. Now
someone "just" needs to step up and do it, Nasser/Martin are
evaluating whether this is something Quic could tackle.
outline an incremental approach to making open source Gerrit
clusterable (the version running for android-review and gerrit-review
is already clustered
but uses much of Google's proprietary technologies such as GFS and
BigTable). The first step which is needed by most other ideas is to
support a very
simple master/master installation of Gerrit where both (or
all if more than 2) masters share a common filesystem backend (likely
a high end NFS server) and a common db.
Two issues need to be resolved before this is possible:
#1 Cache coherency
--some sort of eviction protocol will need to be developed for masters
to inform their peers of a needed eviction.
#2 Submit conflict resolution.
-- could be easily solved by manually determining a submit master and
upgrading to some sort of voting mechanism among peer masters to
choose a submit master, these would be
A simple ssh connection between peers was deemed sufficient in most
cases to accomplish both #1 and #2.
#3 replication from multimasters.
discuss ways to make very remote sites (different continents) with
high latencies able to get a web
UI front end only (ssh would be forwarded to the “master”
...require first solving multi site ref updates without conflicts.
move to discuss multi site masters with separate backends whose
resolving ref updates in a globally safe way.
Google's implementation is placing the refs in BigTable. ZooKeeper
seemed like a good free/open source alternative.
The other piece to solve is moving object data across sites, it was
suggested that ZooKeeper would likely be involved in helping to
coordinate this, but details were not really discussed.
Finally, a distributed filesystem may eventually be needed to scale