A Gerrit Cluster is a set of Gerrit processes sharing the same ServerId and associated to the same set of repositories, accounts, and groups.
It refers to the com.google.gerrit.server.events.Event base abstract class representing any possible action that is generated or received in a Gerrit instance. Actions can be associated with change set status updates, project creations, indexing of changes, etc.
Distributes Gerrit Events to listeners if they are allowed to see them.
Interface for posting events to the Gerrit event system. Implemented by default by com.google.gerrit.server.events.EventBroker. It can be implemented by plugins and allows to influence how events are managed.
Hierarchy of events representing anything that can happen in Gerrit.
API for listening to Gerrit events from plugins, without having any visibility restrictions.
Multi-primary typically refers to configurations where multiple Gerrit primary processes are running in one or more clusters together.
Single cluster multi-primary with shared storage
A variation of multi-primary (a.k.a. HA or high-availability) that shares a file storage volume for the git repositories. These configurations can use the high-availability plugin to synchronize or share caches, indexes, events, and web sessions. The replication plugin also supports synchronizing events using a shared file storage volume.
Multiple clusters multi-primary
Multi-cluster (aka multi-site) primaries typically refers to configurations where multiple Gerrit primary processes are running in different (likely geographically distributed) clusters (sites). This also typically makes use of a multi-primary configuration within each cluster. Synchronization across sites is necessary to detect and prevent split-brain scenarios. These configurations can use the multi-site plugin to facilitate synchronization.
A Gerrit primary is the main Gerrit process permitting write operations by clients. Most installations of Gerrit have only a single Gerrit primary running at a time for their service.
A Gerrit process running with the --replica switch provided. This permits read-only git operations by clients. There is no REST API, WebUI, or search operation available. Replicas can be run in the same cluster with primaries (likely sharing the storage volume) or in other clusters/sites (likely facilitated by the replication plugin).
Command that allows a user via CLI or a plugin to receive in a sequential way some events that are generated in Gerrit. The consumption of the stream by default is available via SSH connection. However, plugins can provide an alternative implementation of the event brokering by sending them over a reliable messaging queueing system (RabbitMQ) or a pub-sub (Kafka).
Part of Gerrit Code Review