Hello Anton! My two cents on this as we don't have a Fluss LTS version right now. So, I don't see any formal need to backport changes. Do you think it is too much to ask to "upgrade to 1.0"?
I'm just afraid we are performing overhead work for these. On the other side, I think it would also be an interesting exercise. I don't know but it may be the first occurrence of a patch version with a backport. On Tue, Apr 21, 2026 at 5:24 PM Anton Borisov <[email protected]> wrote: > Hi all, > > I’d like to propose backporting a small set of Helm chart additions to > the 0.9.x release line. > > All three changes have already landed on main or are in flight, and > they are additive only: they default to empty or disabled and do not > change existing behavior out of the box. > > #3098 - extraEnv / envFrom support (for example, External Secrets > Operator and ConfigMap-driven credentials) > #3114 - pod annotations, pod labels, and PodDisruptionBudget > #3154 - affinity, nodeSelector, tolerations, and topologySpreadConstraints > > The motivation is production adoption. These are effectively Day 1 > requirements for running Fluss on Kubernetes: spreading tablet > replicas across nodes and zones to better tolerate failures under > replication factor 3, wiring in Prometheus scraping and service mesh > labels, protecting quorum during node drains, and injecting > credentials from external secret/config sources. > > Today, users on 0.9.0 generally need to either fork the chart or patch > rendered manifests to get this functionality. > > Two questions for the list: > > * Does it make sense to backport these changes to 0.9.x, or should we > keep them for 0.10? > * Is there anything else Helm- or operator-facing that would be worth > bundling into the same backport? > > Thanks, > Anton > -- Lorenzo Affetti Senior Software Engineer @ Flink Team Ververica <http://www.ververica.com>
