feat(helm): expose scheduling fields (priorityClassName, topologySpreadConstraints) on the gateway workload

Summary

The Helm chart's gateway pod template (templates/_gateway-workload.tpl, shared by both the StatefulSet and Deployment workload shapes) does not expose several standard pod-spec scheduling fields, and the StatefulSet PVC size is hardcoded. This makes it impossible to give the gateway a scheduling priority, spread it across nodes, or size its volume without forking the chart or resorting to out-of-band mutation (Kyverno / post-render patches).

This request is specifically about the upstream-owned gateway workload (both workloadKind: statefulset and workloadKind: deployment, since they share openshell.gatewayPodTemplate). It is not about the sandbox/controller pods.

Observed on chart helm-chart version 0.0.82 and confirmed still present on main.

Current pod-spec knobs exposed by the gateway template

podAnnotations, podLabels, terminationGracePeriodSeconds, imagePullSecrets, hostAliases (via server.hostGatewayIP), podSecurityContext, container securityContext, nodeSelector, affinity, tolerations, resources.

Requested

• priorityClassName — the gateway is a control-plane SPOF; when it shares nodes with the workloads it serves, at the default priority 0 it has no scheduling/eviction advantage over them. A local capacity crunch can node-pressure-evict the gateway and degrade into a fleet-wide outage. Exposing priorityClassName lets operators place the gateway in a higher priority band.

• topologySpreadConstraints — needed to spread gateway replicas across zones/nodes. Today only affinity is available, which is a clumsier tool for even spreading.

• persistence.size / persistence.storageClassName on the StatefulSet — the volumeClaimTemplates currently hardcodes storage: 1Gi with no corresponding value and no way to set a StorageClass:

  volumeClaimTemplates:
    - metadata:
        name: openshell-data
      spec:
        accessModes: ["ReadWriteOnce"]
        resources:
          requests:
            storage: 1Gi
  

  As a result, every fresh install gets a fixed 1Gi PVC on the default StorageClass, with no override. Because volumeClaimTemplates is immutable, there is also no in-place way to grow it later via the chart. Exposing persistence.size and persistence.storageClassName (defaulting to the current 1Gi / unset) fixes this without changing existing behavior.

Both scheduling fields should apply to the StatefulSet and Deployment shapes identically (they render from the same template).

Proposed shape

Standard optional passthroughs, rendered only when set, e.g.:

priorityClassName: ""
topologySpreadConstraints: []
persistence:
  size: 1Gi
  storageClassName: ""

{{- with .Values.priorityClassName }}
priorityClassName: {{ . }}
{{- end }}
{{- with .Values.topologySpreadConstraints }}
topologySpreadConstraints:
  {{- toYaml . | nindent 4 }}
{{- end }}

Contribution

I'm happy to provide the MR for all of the above — the change is small and self-contained. I can't open it yet because my contributor vouch request (#1829) has been open since 2026-06-09 with no response. Once that's approved I'll put the PR up directly.

Start in templates/_gateway-workload.tpl and inspect the chart's values structure used by both StatefulSet and Deployment shapes. Render both workload kinds with the proposed scheduling and persistence values, then verify that unset fields preserve current behavior and that the StatefulSet PVC uses the configured size and storage class.