bitflicker64 commented on code in PR #3381: URL: https://github.com/apache/hugegraph/pull/3381#discussion_r4332838957
########## helm/hugegraph/README.md: ########## @@ -246,7 +246,36 @@ 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. + +Switch PD and Store to images from this version in the same rollout that first +applies `fsGroup`, so the kubelet changes the volume ownership right before the +`10001` image starts. Do not run images that still run as root with this chart +first, for example the published `latest` before it moves to this version: files +they create stay owned by root, and `OnRootMismatch` checks only the volume root, +so it does not fix them later. Pin `pd.image` and `store.image` to a build from +this version rather than relying on `latest`. + +If a release already ran root images with `fsGroup` set, roll out the first +`10001` image with a one-time recursive ownership change, then return to +`OnRootMismatch` on the next upgrade, because `Always` walks the whole volume on +every Pod start: + +```bash +helm upgrade hugegraph ./helm/hugegraph -n hugegraph --reuse-values \ Review Comment: Minor: The one-time recursive rollout can miss its target, and the README does not say how to go back afterwards. Blocking: no. Summary: The command sets only `fsGroupChangePolicy=Always`, under `--reuse-values`. That has two effects. - It keeps whatever image the release already has. A release that still pins the old root tags then spends the `Always` rollout on root images, and the later upgrade that brings the `10001` image runs under `OnRootMismatch` again. The paragraph above asks operators to "Pin `pd.image` and `store.image`", so pinned releases are the expected case. - "Return to `OnRootMismatch` on the next upgrade" does not happen by itself. A `--set` value is saved in the release values, and the main upgrade command in this section (`helm upgrade ... --reuse-values --wait --timeout 15m`, line 240) keeps it. So `Always` stays on, and its whole-volume walk runs on every Pod start, until someone sets the policy back. Evidence: line 245 says `--reuse-values` preserves existing settings. The new unittest "keeps an explicit fsGroupChangePolicy" shows that the helper keeps an explicit `Always`, so nothing in the chart resets it. Requested change: add the image pins to the one-time command, for example `--set pd.image.tag=<this version> --set store.image.tag=<this version>`. Also show the follow-up upgrade: `--reuse-values --set pd.podSecurityContext.fsGroupChangePolicy=OnRootMismatch --set store.podSecurityContext.fsGroupChangePolicy=OnRootMismatch`. -- 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]
