bitflicker64 commented on code in PR #3381:
URL: https://github.com/apache/hugegraph/pull/3381#discussion_r4332020754
##########
helm/hugegraph/README.md:
##########
@@ -246,7 +246,17 @@ helm test hugegraph -n hugegraph --logs --timeout 5m
An easy-mode upgrade that inherits Server/Hubble entry types prints a short
NodePort-default notice in NOTES; explicitly configured entry types are
preserved.
To adopt new defaults, use `--reset-values` with a reviewed values file
retaining
-all settings your release needs. Older explicit helper images also remain under
+all settings your release needs.
+
+PD, Store and Server images built from this version run as UID/GID `10001`. The
+PD and Store pods get `fsGroup: 10001` (with `fsGroupChangePolicy:
OnRootMismatch`)
+unless their `podSecurityContext` sets `fsGroup`, also when `--reuse-values`
keeps
+an older release's empty value, so that user can write PVCs created by older
+images, which ran as root. Because the default tag is `latest` with
+`pullPolicy: Always`, an existing release can pull the new image on any Pod
+restart: upgrade the chart before that happens, or pin the old image tags until
Review Comment:
Important: Both options this paragraph offers leave the PVCs half fixed.
"Upgrade the chart before that happens" and "pin the old image tags" each mean
the release runs the old root image under the new `fsGroup: 10001` with
`OnRootMismatch` for a while. On that first mount the kubelet gives the volume
root group 10001 and the setgid bit. The root process then creates new
directories and files as `root:10001` with the default 022 umask, so 755 and
644. Examples are a new Store partition or graph, raft snapshots and RocksDB
files. When the 10001 image arrives, `OnRootMismatch` checks only the volume
root. `requiresPermissionChange` in kubelet `pkg/volume/volume_linux.go` stats
`rootDir` alone, finds it matching and skips the recursive change. UID 10001
then cannot create or delete entries in those directories and gets `Permission
denied`. `docs/operations.md` already describes this case ("files that image
created can stay unwritable"), but this paragraph steers the operator into it
and links there only after a Pod fails. A fresh install from this chart hits
the same case while the published `latest` images still run as root.
Requested change: tell the operator to switch to the new images in the same
rollout that first adds `fsGroup`, so the kubelet's recursive change runs right
before the 10001 image starts. For a release that already ran root images with
`fsGroup` set, roll out the first 10001 image with `--set
pd.podSecurityContext.fsGroupChangePolicy=Always --set
store.podSecurityContext.fsGroupChangePolicy=Always`, then go back to
`OnRootMismatch`. The helper keeps an explicit policy and still adds `fsGroup`,
so this also works under `--reuse-values`. Defaulting the policy to `Always`
would close the gap without operator action, at the cost of a recursive walk on
every Pod start.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
