How can we help maintainers to keep a more frequent release cycle?

[silveiralexf]

Description

Hi there folks, hope all is well on your side! We've been using this project for a while and thank the team for the great work!

However, like already mentioned in past issues, we've also been struggling with the lack of new releases, which force us to fork the images and Helm charts internally to keep patching for CVE's and adding some of the small fixes already reported.

We've noticed multiple PR's have already been sent for bumps and fixes (and in some cases already merged), but new releases are still not being published, and the last references I could find about plans for a new release are over a year old.

Please note this is not at all, a rant or anything like that -- just trying to reach out to check how can we help support maintainers to keep release cycles going in a more frequent basis?

Though we found a few forks in the wild, and even considered in our company to do the same internally, I believe as most folks mentioned in different issues, a better approach would be keeping the project going forward. But start sending PR's would only make sense if maintainers confirm there are still plans for future releases, or if is there openness for new volunteers to step-in to help publishing new releases.

Again, thanks for the great work!

Importance

Blocker: Docker images are lacking updates for Linux, Java, and Zookeeper itself, which blocks us from using the operator in our production environments, where high severity CVE's are a no go, without maintaining internal forks.

Location

This affects the Docker image for Zookeeper, the operator image and dependencies itself and the Helm charts, as referenced in different issues, such as:

• Release newer zookeeper docker image #514
• Release new zookeeper operator with log4j fix #574

Suggestions for an improvement

• Update the operator tooling, such as Kustomize, Controllergen and Kubebuilder itself -- as the project fails to build locally with the existing versions and multiple fixes have already been made on these to
• Upgrade Go from 1.21 to 1.22+ along with the project's dependencies, as multiple high severity CVE's are easily updated with this bump -- I've performed tests locally, and the only code changes that were needed were small adjusts regarding metrics, as per below all vulnerabilities can be fixed with just this update:

trivy image --ignore-unfixed docker.io/pravega/zookeeper-operator:0.2.15-10-dirty  --skip-update --offline-scan
2024/10/01 08:03:44 WARN '--skip-update' is deprecated. Use '--skip-db-update' instead.
2024-10-01T08:03:44+01:00       INFO    [vuln] Vulnerability scanning is enabled
2024-10-01T08:03:44+01:00       INFO    [secret] Secret scanning is enabled
2024-10-01T08:03:44+01:00       INFO    [secret] If your scanning is slow, please try '--scanners vuln' to disable secret scanning
2024-10-01T08:03:44+01:00       INFO    [secret] Please see also https://aquasecurity.github.io/trivy/v0.54/docs/scanner/secret#recommendation for faster secret detection
2024-10-01T08:03:44+01:00       INFO    Detected OS     family="debian" version="11.10"
2024-10-01T08:03:44+01:00       INFO    [debian] Detecting vulnerabilities...   os_version="11" pkg_num=3
2024-10-01T08:03:44+01:00       INFO    Number of language-specific files       num=1
2024-10-01T08:03:44+01:00       INFO    [gobinary] Detecting vulnerabilities...

docker.io/pravega/zookeeper-operator:0.2.15-10-dirty (debian 11.10)

Total: 0 (UNKNOWN: 0, LOW: 0, MEDIUM: 0, HIGH: 0, CRITICAL: 0)

• The same applies for the Zookeeper image itself, we already been keeping a fork of it internally in our company without any high severity CVE's as well, and would gladly contribute sending a PR with the required changes.
• Default metrics are not being exposed, though Issue-581 Make metrics exposable based on helm variables #582 has provided a way to workaround the issue, the changes were not yet published as a new release since last year.
• Other security issues such as The pravega zookeeper docker image run as root by default #538 and Zookeeper Operator POD does not support securityContext override #562 can be easily fixed with small changes to the charts, just like some improvements can also be made to reduce some of the cluster level permissions, as mentioned in Enhancement: Use Namespaced RBAC over Cluster RBAC #611
• Using private registries for the Zookeeper cluster is also a bit convoluted, as mentioned in ImagePullSecrets added in zookeepercluster doesn't work for zookeeper intance pod #593, as setting the imagePullSecrets to the cluster resource itself has no effect, the only way we managed to work around the problem was by sharing the operator serviceAccount with the cluster, which requires a permissive access to be granted for it to work (cluster scope).

The main point of this issue is reaching out to maintainers to see how can we help, and to confirm if there are plans for new releases or perhaps allowing new contributors to step in to help keeping a more frequent release cycle.

Again, thanks for the great work!

[RaulGracia]

Thanks @silveiralexf, and sorry for the late reply. To your question: yes, I think that it would be a good idea to adding more committers to this repository, opening up for new contributions. If you want, we can continue this discussion in the Pravega Slack space.

[janhoy]

Hi. It’s been 2 months. What concrete steps or decisions have been made so far wrt inviting committers to the project, and for the next release?

[cheleb]

Hi,
I would be really happy to rampup on the codebase ... even if my java is rather old now ... ( Scala developer for 11+ years).
I wrote and maintain Scala connector for Akka and ZIO, I really love Pravega <3
HIH

[RaulGracia]

Thanks @janhoy and @cheleb for your interest. I started a conversation with @silveiralexf via Slack for adding more committers to the project, and therefore open the ability of the community to make more progress in the development. Unfortunately, @silveiralexf has not yet provided 1/2 candidate committers from his side. I'm open to continue this conversation, so if you are interested please let's talk via Slack so we can get started the voting process for adding new committers. Thanks!