Is there an existing issue already for this feature request/idea?

• I have searched for an existing issue, and could not find anything. I believe this is a new feature request to be evaluated.

What problem is this feature going to solve? Why should it be added?

Currently, during restored cluster handling, pods may be deleted even if some of their init containers (that do not have restartPolicy set to Always) are still running. This behavior can cause issues with unfinished initialization processes carrying out the actual data copy.

Describe the solution you'd like

Enhance the logic in the ensureClusterRestoreCanStart function in internal/controller/cluster_restore.go to wait for the completion of any init container that does not have a restart policy of Always before proceeding with pod deletion.

Describe alternatives you've considered

Alternative solutions considered:

• Not checking the state of init containers and deleting pods immediately (current behavior, which is unsafe)
• Deleting pods after a fixed wait time (not as robust or specific to init container states)

The proposed solution actively inspects pod status and init container policies, providing correct and explicit handling.

Additional context

Related code: internal/controller/cluster_restore.go, specifically the ensureClusterRestoreCanStart function, where this logic can be inserted. The new logic should check pods managed for restoration and ensure no init container (without restartPolicy=Always) is running before deleting the pod.

Backport?

No

Are you willing to actively contribute to this feature?

Yes

Code of Conduct

• I agree to follow this project's Code of Conduct