Problem
When backends.kubernetes.enabled: true, content jobs won't launch unless the service account they run as has the connect.posit.co/service-account=true label. The upgrade guide tells users to apply this label manually with kubectl label sa ....
If the chart creates the SA itself, users still have to remember to add the label via rbac.serviceAccount.labels. If they forget, content jobs fail with no obvious error at install time.
Proposal
When both of these are true, the chart should add the label automatically on the SA it creates:
rbac.serviceAccount.create: truebackends.kubernetes.enabled: true
Any labels the user sets via rbac.serviceAccount.labels would still apply alongside the auto-added one.
What wouldn't change
rbac.serviceAccount.create: false — chart doesn't own the SA, so labeling stays manual.- Content jobs pinned to a different SA via
defaultResourceJobBase.spec.template.spec.serviceAccountName — chart can't know if it manages that SA, so labeling stays manual for those cases.
Why
The chart already auto-wires several settings when backends.kubernetes.enabled: true (e.g. DefaultResourceJobBase, ExecutionEnvironments.ConfigFilePath, Role/RoleBinding). Adding the label fits the same pattern, and missing it is a common gotcha that's hard to debug.
Docs
The upgrade guide at examples/connect/upgrade-launcher-to-kubernetes/launcher-to-kubernetes.qmd should be updated alongside the chart change to note that the chart handles labeling in the default case, and that the manual kubectl label sa ... step only applies to BYO SAs or SAs pinned via serviceAccountName in the job base.
Problem
When
backends.kubernetes.enabled: true, content jobs won't launch unless the service account they run as has theconnect.posit.co/service-account=truelabel. The upgrade guide tells users to apply this label manually withkubectl label sa ....If the chart creates the SA itself, users still have to remember to add the label via
rbac.serviceAccount.labels. If they forget, content jobs fail with no obvious error at install time.Proposal
When both of these are true, the chart should add the label automatically on the SA it creates:
rbac.serviceAccount.create: truebackends.kubernetes.enabled: trueAny labels the user sets via
rbac.serviceAccount.labelswould still apply alongside the auto-added one.What wouldn't change
rbac.serviceAccount.create: false— chart doesn't own the SA, so labeling stays manual.defaultResourceJobBase.spec.template.spec.serviceAccountName— chart can't know if it manages that SA, so labeling stays manual for those cases.Why
The chart already auto-wires several settings when
backends.kubernetes.enabled: true(e.g.DefaultResourceJobBase,ExecutionEnvironments.ConfigFilePath, Role/RoleBinding). Adding the label fits the same pattern, and missing it is a common gotcha that's hard to debug.Docs
The upgrade guide at
examples/connect/upgrade-launcher-to-kubernetes/launcher-to-kubernetes.qmdshould be updated alongside the chart change to note that the chart handles labeling in the default case, and that the manualkubectl label sa ...step only applies to BYO SAs or SAs pinned viaserviceAccountNamein the job base.