fix: fsGroup=101 on Odoo pod (Longhorn PVCs come up root-owned, Odoo crashes on first session write)

templates/odoo-deployment.yaml

@@ -28,6 +28,23 @@ spec:
         # values.yaml would leave the existing pod alone.
         odoosky.io/addons-hash: {{ .Values.addons | toJson | sha256sum | trunc 16 }}
     spec:
+      # fsGroup=101 makes the kubelet recursively chown the filestore
+      # PVC's root inode to gid=101 on attach. Odoo runs as uid 101
+      # and writes /var/lib/odoo/sessions on first request; without
+      # this it crashes "Permission denied: '/var/lib/odoo/sessions'"
+      # on the first hit because Longhorn-formatted PVCs come up
+      # owned by root:root. (k3s local-path masked this — its hostPath
+      # provisioner left the dir world-writable. Real CSI drivers
+      # don't.) supplementalGroups + runAsUser kept default so the
+      # rest of the pod (db-init, addon init containers) keeps the
+      # behavior they already had.
+      securityContext:
+        fsGroup: 101
+        # OnRootMismatch: only recursive-chown when the volume root
+        # ISN'T already gid=101. Saves O(filestore-size) chmod cost
+        # on every pod restart for instances with millions of files.
+        # Defaults work for fresh PVCs (root != 101 → chown once).
+        fsGroupChangePolicy: OnRootMismatch
       # Bootstrap initContainers always run; addon initContainers only
       # run when there are addons. We always need db-init to ensure the
       # tenant DB exists + base module is initialized before Odoo's