Automated verification process: Run tests automatically to verify changes.
Most tests in the project require a Kubernetes cluster and some additional prerequisites, e.g. istio. Currently, the Gerrit OpenSOurce community does not have these resources. At SAP, we plan to run verification in our internal systems, which won't be publicly viewable, but could already vote. Builds would only be triggered, if a maintainer votes +1 on the Build-Approved-label.
Builds can be moved to a public CI at a later point in time.
Automated publishing of container images: Publishing container images will happen automatically on ref-updated using a CI.
Support for multiple Gerrit versions: All currently supported Gerrit versions will also be supported in k8s-gerrit.
Currently, container images used by this project are only published for a single Gerrit version, which is updated on an irregular schedule. Introducing stable branches for each gerrit version will allow to maintain container images for multiple Gerrit versions. Gerrit binaries will be updated with each official release and more frequently on master. This will be (at least partially) automated.
Versioning of CRDs: Provide migration paths between API changes in CRDs.
At the moment updates to the CRD are done without providing a migration path. This means a complete reinstallation of CRDS, Operator, CRs and dependent resources is required. This is not acceptable in a productive environment. Thus, the operator will always support the last two versions of each CRD, if applicable, and provide a migration path between those versions.
High-availability: Primary Gerrit StatefulSets will have limited support for horizontal scaling.
Scaling will be enabled using the high-availability plugin. Primary Gerrits will run in Active/Active configuration. Support of two primary Gerrit instances, i.e. 2 pods in a StatefulSet, is the aim, but more instances might be possible.
Global RefDB support: Global RefDB will add support for Active/Active configurations of multiple primary Gerrits.
The Global RefDB support is required for high-availability as described in the previous point. The Gerrit Operator will automatically set up Gerrit to use a Global RefDB implementation. Support for following implementations is planned:
The Gerrit Operator will not set up the database used for the Global RefDB. It will however manage plugin/module installation and configuration in Gerrit and service mesh integration (might differ depending on ingress/service mesh provider).
Log collection: Support addition of sidecar running a log collection agent to send logs of all components to some logging stack.
Planned supported log collectors:
Automated reload of plugins: Reload plugins on configuration change.
Configuration changes in plugins typically don‘t require a restart of Gerrit, but just to reload the plugin. To avoid unnecessary downtime of pods, the Gerrit Operator will only reload affected plugins and not restart all pods, if only the plugin’s configuration changed.
Support for additional Ingress controllers: Add support for setting up routing configurations for additional Ingress controllers
Additional ingress controllers might include:
Support for additional log collection agents:
Additional log collection agents might include:
Only limited support is planned for the gerrit and gerrit-replica helm-charts as soon as the Gerrit Operator reaches version 1.0. The reason is that the double maintenance of all features would not be feasible with the current number of contributors. The Gerrit Operator will support all features that are provided by the helm charts. If community members would like to adopt maintainership of the helm-charts, this would be very much appreciated and the helm-charts could then continued to be supported.