Currently files which are managed via the File-Manager are deleted in the Rover-Server, however, this introduces an orphan risk, e.g.
Current Deletion Order:
- Delete File from File-Manager via FileId
- if successful, delete CR from cluster
- Deletion of CR is a no-op in handler
- if delete of CR fails, fileId points to nothing
Proposed Improvement:
- Delete CR from cluster
- Deletion of CR in handler deletes File from File-Manager
- if successful, remove finalizer
- CR is deleted
This is a minor issue which only becomes a problem if the k8sClient.Delete(...) in rover-server fails.
Currently files which are managed via the File-Manager are deleted in the Rover-Server, however, this introduces an orphan risk, e.g.
Current Deletion Order:
Proposed Improvement:
This is a minor issue which only becomes a problem if the k8sClient.Delete(...) in rover-server fails.