Repository navigation
feat(helm): expose scheduling fields (priorityClassName, topologySpreadConstraints) on the gateway workload #2342
Description
Activity
- addedstate:triage-neededOpened without agent diagnostics and needs triageOpened without agent diagnostics and needs triage
on Jul 17, 2026 📋 triage-agent
Triage Assessment
Classification: feature-valid
Summary
The gateway scheduling and persistence gaps are valid, and the proposed optional values preserve existing chart behavior.
Investigation
deploy/helm/openshell/templates/_gateway-workload.tplexposes node selectors, affinity, and tolerations, but notpriorityClassNameortopologySpreadConstraints.templates/statefulset.yamlstill hardcodes the gateway PVC to1Giwithout a StorageClass override on both v0.0.92 andorigin/main. PR #2463 only added StorageClass configuration for sandbox workspace PVCs and does not duplicate this request.Recommendation
Keep the issue open as a bounded Helm enhancement. Add render/unit coverage for both workload kinds and the StatefulSet PVC defaults.
- addedarea:clusterRelated to running OpenShell on k3s/dockerRelated to running OpenShell on k3s/dockerand removedstate:triage-neededOpened without agent diagnostics and needs triageOpened without agent diagnostics and needs triage
on Jul 29, 2026 @matthewgrossman could you pleae approve my vouch request I have a PR for this #2610
Hi @matthewgrossman I've put in an MR for this is a relatively minor change but nice to have
especially the hardcoded PVC size with no storageClass its something that I have forked, as some guys i work with are crazy enough to want to run 1000+ sandboxes on a GW and 1gb obviously does not cut it instead we just override the helm chart
This issue has had no activity for 14 days and is now marked stale. It may be closed in 7 days if there is no further activity. Comment or remove the state:stale label to keep it open.
- addedstate:staleInactive item at risk of automatic closure.Inactive item at risk of automatic closure.
on Sep 4, 2026 The existing pr solves the issue I am facing on my cluster which doesnt have a default storageclass.
- removedstate:staleInactive item at risk of automatic closure.Inactive item at risk of automatic closure.
on Sep 23, 2026 This issue has had no activity for 14 days and is now marked stale. It may be closed in 7 days if there is no further activity. Comment or remove the state:stale label to keep it open.
- addedstate:staleInactive item at risk of automatic closure.Inactive item at risk of automatic closure.
on Oct 7, 2026
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: statefulsetandworkloadKind: deployment, since they shareopenshell.gatewayPodTemplate). It is not about the sandbox/controller pods.Observed on chart
helm-chartversion0.0.82and confirmed still present onmain.Current pod-spec knobs exposed by the gateway template
podAnnotations,podLabels,terminationGracePeriodSeconds,imagePullSecrets,hostAliases(viaserver.hostGatewayIP),podSecurityContext, containersecurityContext,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 priority0it has no scheduling/eviction advantage over them. A local capacity crunch can node-pressure-evict the gateway and degrade into a fleet-wide outage. ExposingpriorityClassNamelets operators place the gateway in a higher priority band.topologySpreadConstraints— needed to spread gateway replicas across zones/nodes. Today onlyaffinityis available, which is a clumsier tool for even spreading.persistence.size/persistence.storageClassNameon the StatefulSet — thevolumeClaimTemplatescurrently hardcodesstorage: 1Giwith no corresponding value and no way to set a StorageClass:As a result, every fresh install gets a fixed 1Gi PVC on the default StorageClass, with no override. Because
volumeClaimTemplatesis immutable, there is also no in-place way to grow it later via the chart. Exposingpersistence.sizeandpersistence.storageClassName(defaulting to the current1Gi/ 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.:
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.