fix(storage): make zfs-pool-init re-run when its script changes #408
Loading…
Reference in a new issue
No description provided.
Delete branch "fix/zfs-pool-init-reload"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
zfs-pool-initmounts its script from a ConfigMap, and a ConfigMap edit does not restart a pod. The DaemonSet had no reload trigger, so it silently ignored every change to the dataset tuning.That bit immediately. #404 added
tank/buildkit-{32k,128k,1m}and three StorageClasses pointing at them. The manifest rendered, Flux reconciled, andopenebs-zfsreported Ready — while the pool-init pods were 22 days old and had never run the new script.zfs liston all five workers showed zerotank/buildkit-*lines, so all three classes referenced parent datasets that did not exist. A PVC on any of them would have failed to provision and nothing in the tree would have said why.Reloader is deployed here and ignores only jobs and cronjobs, so it watches DaemonSets. The annotation makes a script change roll the fleet — and deploying this change is itself what creates the missing datasets.
tests/zfs-buildkit-classes.shnow fails if the trigger goes away. Its first version read the wrong DaemonSet (this manifest has two, andopenebs-zfs-localpv-nodecomes first), so it selects by name. Verified against both mutations: annotation removed, and annotation moved onto the other DaemonSet.https://claude.ai/code/session_01KZoQin34jeyt6nDGqvJA76