Description of feature
dokku_storage_entry keys idempotency on the entry name alone. When an entry with that name exists the task reports in sync no matter what the recipe says about the other fields, so chown, size, namespace, reclaim_policy, annotations, and labels are applied once at create time and never again. Flipping chown: herokuish to chown: root in a recipe is a silent no-op, and plan agrees that nothing would change.
The struct comment states this outright, so it is a known design choice rather than an oversight. What makes it worth revisiting is that #416 settled the surrounding question: dokku_storage_entry is where host directory ownership lives, and ownership that only converges on the first run is the weakest part of that claim. ansible-dokku's dokku_storage chowns on every run.
It is not a matter of adding a diff to Plan(), which is why it was split out. storage:set --chown writes the new value into the entry JSON but never re-runs the chown on a docker-local directory, so the command that reads like the fix does not actually change anything on disk. The command that does re-chown is a second storage:create, which is idempotent and calls ensureDockerLocalPath again - but it rewrites every recorded attribute from whatever the task supplies, so a recipe that names only name and chown would clear a size or namespace it never mentioned. On k3s the opposite holds: storage:set is the right command because it merges, and it carries the guards that refuse an access-mode or storage-class swap in place.
So converging attributes means picking a command per scheduler per field, and deciding what a partially-declared recipe is allowed to clear. Worth doing, worth doing deliberately.
Description of feature
dokku_storage_entrykeys idempotency on the entry name alone. When an entry with that name exists the task reports in sync no matter what the recipe says about the other fields, sochown,size,namespace,reclaim_policy,annotations, andlabelsare applied once at create time and never again. Flippingchown: herokuishtochown: rootin a recipe is a silent no-op, andplanagrees that nothing would change.The struct comment states this outright, so it is a known design choice rather than an oversight. What makes it worth revisiting is that
#416settled the surrounding question:dokku_storage_entryis where host directory ownership lives, and ownership that only converges on the first run is the weakest part of that claim.ansible-dokku'sdokku_storagechowns on every run.It is not a matter of adding a diff to
Plan(), which is why it was split out.storage:set --chownwrites the new value into the entry JSON but never re-runs the chown on a docker-local directory, so the command that reads like the fix does not actually change anything on disk. The command that does re-chown is a secondstorage:create, which is idempotent and callsensureDockerLocalPathagain - but it rewrites every recorded attribute from whatever the task supplies, so a recipe that names onlynameandchownwould clear asizeornamespaceit never mentioned. On k3s the opposite holds:storage:setis the right command because it merges, and it carries the guards that refuse an access-mode or storage-class swap in place.So converging attributes means picking a command per scheduler per field, and deciding what a partially-declared recipe is allowed to clear. Worth doing, worth doing deliberately.