The issue occurs during ODF DRPolicy creation. Before creating the DRPolicy, the workflow first creates or prepares the required MirrorPeer resource. If the MirrorPeer creation succeeds but the subsequent DRPolicy creation fails, there is no rollback mechanism to remove the MirrorPeer that was just created.
Current flow:
Create MirrorPeer ====> Create DRPolicy ====> Fails ====> Exit with Error
At this point, the newly created MirrorPeer remains in the cluster even though the DRPolicy was never created.
The fundamental issue is that this is a multi-step operation, but it is not treated as a transaction. If a later step fails, the resources created by earlier steps should be cleaned up whenever possible to avoid leaving the system in an inconsistent state.
A realistic scenario is when prepareOdfPeering() successfully creates the MirrorPeer, but the createDRPolicy() call fails due to validation errors, an API server error, a temporary network issue, or the DRPolicy already existing. The user sees that DRPolicy creation failed, but the MirrorPeer created during the attempt is still present.
When the user retries creating the DRPolicy, the existing MirrorPeer may cause conflicts or confusing errors such as "MirrorPeer already exists", even though the previous operation was reported as a failure. The user is then forced to manually clean up the orphaned resource before retrying.
The recommended fix is to implement compensating rollback logic. If the MirrorPeer was created as part of the current operation and the subsequent DRPolicy creation fails, the code should delete the newly created MirrorPeer before returning the error.
The rollback should only delete the MirrorPeer if it was created during the current request, not if it already existed before the operation started. This keeps the cluster consistent, prevents orphaned resources, and makes retries predictable and user-friendly.
The issue occurs during ODF DRPolicy creation. Before creating the DRPolicy, the workflow first creates or prepares the required MirrorPeer resource. If the MirrorPeer creation succeeds but the subsequent DRPolicy creation fails, there is no rollback mechanism to remove the MirrorPeer that was just created.
Current flow:
At this point, the newly created MirrorPeer remains in the cluster even though the DRPolicy was never created.
The fundamental issue is that this is a multi-step operation, but it is not treated as a transaction. If a later step fails, the resources created by earlier steps should be cleaned up whenever possible to avoid leaving the system in an inconsistent state.
A realistic scenario is when
prepareOdfPeering()successfully creates the MirrorPeer, but thecreateDRPolicy()call fails due to validation errors, an API server error, a temporary network issue, or the DRPolicy already existing. The user sees that DRPolicy creation failed, but the MirrorPeer created during the attempt is still present.When the user retries creating the DRPolicy, the existing MirrorPeer may cause conflicts or confusing errors such as "MirrorPeer already exists", even though the previous operation was reported as a failure. The user is then forced to manually clean up the orphaned resource before retrying.
The recommended fix is to implement compensating rollback logic. If the MirrorPeer was created as part of the current operation and the subsequent DRPolicy creation fails, the code should delete the newly created MirrorPeer before returning the error.
The rollback should only delete the MirrorPeer if it was created during the current request, not if it already existed before the operation started. This keeps the cluster consistent, prevents orphaned resources, and makes retries predictable and user-friendly.