feat(helm): add podSecurityContext - #175
Merged
Merged
Conversation
matlaj
requested review from
MarshallAsch and
cookandy
and removed request for
a team
August 23, 2026 21:00
…curityContext
`pms.securityContext` is documented as "Security context for PMS pods", but it
renders into the container's securityContext, and the chart has no pod-level
securityContext hook at all.
That mismatch silently discards pod-only fields. Setting `fsGroup` -- the
documented way to make the config volume group-writable -- produces a manifest
where `fsGroup` sits in a container securityContext, which the API server drops.
The chart installs cleanly and the setting simply never takes effect.
Add `pms.podSecurityContext`, rendered on the pod spec, and correct both doc
strings to say which level they apply to.
Backward compatible: `pms.securityContext` keeps rendering exactly where it did,
and the new value defaults to `{}`, which emits nothing.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
matlaj
force-pushed
the
fix/pod-security-context
branch
from
August 23, 2026 21:07
3316a65 to
07fadf4
Compare
cilindrox
changed the title
cilindrox
changed the title
cilindrox
added a commit
that referenced
this pull request
Sep 7, 2026
* feat(chart): add startupProbe support to the pms container The chart supports livenessProbe and readinessProbe (#117) but not startupProbe, which forces a bad trade-off for anyone using probes. PMS answers 503 on /identity in two very different situations: 1. while it runs database migrations at startup — transient, can take many minutes on a large library, and restarting makes it worse because the migration starts over; 2. when the server is wedged and will never recover on its own. Only a liveness probe catches (2), because the process stays alive. But with no startupProbe available, the liveness budget has to be stretched to cover the worst case of (1), or it turns a slow migration into a restart loop — the exact risk raised in the review of #117: "if it's a particularly long db migration, the restart will just result in it being run again from the beginning and will indefinitely until the migration is allowed enough time to complete." startupProbe is the primitive that separates the two: it holds the liveness probe off until the container answers once, then hands over. With it, the same deployment can tolerate a long migration and still keep a tight liveness probe afterwards. Changes, with no behaviour change unless the new value is set: - templates/statefulset.yaml: one {{- with }} block mirroring the existing two, placed before livenessProbe. - values.yaml: startupProbe: {} with a commented-out example, in the same style as its neighbours. - README.md: helm-docs row. - Chart.yaml: 1.7.1 -> 1.8.0, matching how #168, #170 and #175 each bumped the minor version for an additive feature. Verified: `helm template` with no values renders byte-identically to before apart from the helm.sh/chart label; with startupProbe and livenessProbe both set, both render correctly nested and readinessProbe stays absent; the rendered manifest passes kubectl apply --dry-run=server against a live cluster. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Update charts/plex-media-server/values.yaml Co-authored-by: Gaston Festari <cilindrox@gmail.com> * docs(chart): regenerate README with helm-docs Chart.yaml was bumped to 1.8.0 and the pms.startupProbe comment in values.yaml was reworded, but README.md was never regenerated, so the lint job's `helm-docs --chart-search-root charts` + `git diff --exit-code` check failed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VqVXMTaVmKbkeF3XevLMoJ --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-authored-by: Gaston Festari <cilindrox@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
pms.securityContextis documented as "Security context for PMS pods", but it renders into the container's securityContext, and the chart has no pod-level securityContext hook at all.That mismatch silently discards pod-only fields. Setting
fsGroup-- the documented way to make the config volume group-writable -- produces a manifest wherefsGroupsits in a container securityContext, which the API server drops. The chart installs cleanly and the setting simply never takes effect.Add
pms.podSecurityContext, rendered on the pod spec, and correct both doc strings to say which level they apply to.Backward compatible:
pms.securityContextkeeps rendering exactly where it did, and the new value defaults to{}, which emits nothing.Co-Authored-By: Claude Opus 5 noreply@anthropic.com