Open bernardgut opened 3 months ago
Is there any "easy" way for the operator to recreate automagically the linstor resources associated with this pvc such that I can then bind it to an existing workload.
The answer is no. If you nuke the kube API LINSTOR will lose it's state. You could create a script that tries to find the "most plausible" state by looking at existing backing devices and DRBD metadata (i.e. all zvols and LVs will be named "pvc-
If you then use that collected information to make the appropriate API requests to LINSTOR, you could get LINSTOR to nearly the original state. Afterwards you would just have to translate the LINSTOR resources to PV and PVCs, which should be relatively straight forward.
I see. I guess at that point it is just easier to do somethging along the lines of
zfs send originpool/old-pvc@snapshot | zfs receive destinationpool/new-pvc
that should work right ?
Hello
Lets say I run a Talos cluster with some Piraeus/Linstor/DRBD backed by ZFSTHIN datasets (or LVM PVs for that mater). Lets say I recreate the cluster for xyz reason (I lost the Piraeus operator state). The storage datasets (PVs) are still there on the nodes physical disks. How would you "import" them back into Piraeus/Linstor/DRBD CSI stack (If possible at all) ??
I will give you a concrete example :
This morning a nuked a cluster. Upon recreation the cluster is "clean" (
k linstor resource list-volumes
returns null). On two of the nodes I have :Is there any "easy" way for the operator to recreate automagically the linstor resources associated with this pvc such that I can then bind it to an existing workload ? How would you go on about this ?
thanks B.