You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm using gitops to deploy everything in kubernetes. When reinstalling the cluster, the same pods/statefulsets/deployment are created exactly the same, which triggers the same PVCs.
This trigers the failure in the csi provider:
failed to provision volume with StorageClass "freenas-iscsi-csi": rpc error: code = Unknown desc = received error creating iscsi target - code: 422 body: {"iscsi_target_create.name":[{"message":"Target with this name already exists","errno":22}]}
IMO it would be great if two different behaviours would be configurable:
Adopt: take the target and use it as existing.
Same name should not be a conflict and the naming should not be conflicting (and then Velero or any other recovery tool can be used)
Additionally: When I manually deleted the portal, CSI went ahead and provisioned the portal, and everything seems to be working. I was really surprised when the previous data was still present. I've been digging and it seems that the mapping of the extent to the dataset from the previous volume was still present, so it mapped to the old lun. This means that the system ends up in an inconsistent state if you go and tinker with things manually, which makes sense. Just added this comment to give you the info about the previous extent mapping.
pvcs: pvc-0d06a23f-b6f8-41e3-b592-3439bd3add52 and pvc-225a46ec-e677-4b61-93d3-5d0c1ef5a10b do not exist on the cluster.
The text was updated successfully, but these errors were encountered:
Hi!
I'm using gitops to deploy everything in kubernetes. When reinstalling the cluster, the same pods/statefulsets/deployment are created exactly the same, which triggers the same PVCs.
This trigers the failure in the csi provider:
IMO it would be great if two different behaviours would be configurable:
Additionally: When I manually deleted the portal, CSI went ahead and provisioned the portal, and everything seems to be working. I was really surprised when the previous data was still present. I've been digging and it seems that the mapping of the extent to the dataset from the previous volume was still present, so it mapped to the old lun. This means that the system ends up in an inconsistent state if you go and tinker with things manually, which makes sense. Just added this comment to give you the info about the previous extent mapping.
pvcs: pvc-0d06a23f-b6f8-41e3-b592-3439bd3add52 and pvc-225a46ec-e677-4b61-93d3-5d0c1ef5a10b do not exist on the cluster.
The text was updated successfully, but these errors were encountered: