Persistence

[benjaminpreiss]

Hey everyone,

I am using helmfile to deploy openebs local pv hostpath + minio, but I am having problems with persistency.

After running helmfile destroy and helmfile apply the previous data is deleted.
I have reclaimPolicy: Delete set currently, though, so that might be the problem.

Taken from #479 (comment)

It should be perhaps added, that while the data and the PV itself (auto-created when PVC is created under reclaimPolicy: Retain) will be preserved after deleting the PVC, the uderlying user data will still have to be manually copied to the new PV, which will be created fresh and empty, in spite of the PVC preserving the same name as previously, which is a bit of a bug IMHO (tested under OpenEBS Host Path StorageClass, but much less obvious - if at all doable - under Jiva).

This implies to me that even reclaimPolicy: Retain does achieve persistence across helmfile destroy, but the persistent volume is not picked up by the pod again.
Taken from the helmfile docs:

destroy basically runs helm uninstall --purge on all the targeted releases.

So I wonder then: Can I never run helmfile destroy to get persistence? Do other (local or replicated) storage classes, like zfs, lvm or mayastor react differently? Or do I need to define a StatefulSet to define which pod is bound to which persistent volume?

Find a reproduction repo here: https://github.com/frontline-hq/backups-unstoppable

Would be very glad to get some more insight into persistence in openebs

[benjaminpreiss]

Genius on reddit helped me find the solution. It's reclaimPolicy: Retain and removing the claimRef on the pv.

Taken from reddit:

Check the claimRef on the released PVs. If it’s not empty - which I suspect it isn’t and is still claimed by now deleted PVCs - delete the entry to switch the PV back to Available. Then new PVCs can bind to it.