Hey — small chart gap I hit deploying on EKS. charts/restate-operator-helm/values.yaml only exposes affinity: {}, so there's no way to set tolerations or nodeSelector on the operator pod through helm values.
Our cluster taints node groups per-workload (service:NoSchedule) so out of the box the operator pod just sits Pending. The DaemonSets the operator manages are fine — EKS auto-tolerates system addons — and RestateCluster.spec.compute already exposes the full scheduling block so the runtime is fine too. It's only the operator's own Deployment that doesn't have a way through.
Patching it with kustomize+helm right now, but it'd be nicer to drop that.
Would you take a PR adding tolerations, nodeSelector, and topologySpreadConstraints next to the existing affinity? Same pattern most other operator charts use (cert-manager, external-secrets, etc) — defaults empty, no behavior change. If not, happy to take a recommendation on how we get around this.
Hey — small chart gap I hit deploying on EKS. charts/restate-operator-helm/values.yaml only exposes affinity: {}, so there's no way to set tolerations or nodeSelector on the operator pod through helm values.
Our cluster taints node groups per-workload (service:NoSchedule) so out of the box the operator pod just sits Pending. The DaemonSets the operator manages are fine — EKS auto-tolerates system addons — and RestateCluster.spec.compute already exposes the full scheduling block so the runtime is fine too. It's only the operator's own Deployment that doesn't have a way through.
Patching it with kustomize+helm right now, but it'd be nicer to drop that.
Would you take a PR adding tolerations, nodeSelector, and topologySpreadConstraints next to the existing affinity? Same pattern most other operator charts use (cert-manager, external-secrets, etc) — defaults empty, no behavior change. If not, happy to take a recommendation on how we get around this.