Skip to content

Conversation

@alexeyklyukin
Copy link
Contributor

When there is an error happening upon deletion of the Kubernetes object
belonging to the cluster being removed, it makes no sense to abort the
deletion: the manifest will be removed anyway, therefore all the objects
after the one we aborted at will stay forever.

When there is an error happening upon deletion of the Kubernetes object
belonging to the cluster being removed, it makes no sense to abort the
deletion: the manifest will be removed anyway, therefore all the objects
after the one we aborted at will stay forever.
@coveralls
Copy link

Coverage Status

Coverage increased (+0.004%) to 11.336% when pulling 27c7245 on continue_on_delete_errors into f5d61a5 on master.

@mgomezch
Copy link
Contributor

@alexeyklyukin
Copy link
Contributor Author

This partially addresses #218 , as it will not stop deletion when the object to delete is not there; however, it will also continue on any other error, as delete is a one-shot operation: once the CRD is removed the operator leaves no traces of the cluster existence (we could avoid removing the in-memory structures, but that wouldn't suffice in case the operator is restarted somewhere after the unsuccessful deletion).

@alexeyklyukin
Copy link
Contributor Author

👍

1 similar comment
@sdudoladov
Copy link
Member

👍

@sdudoladov sdudoladov merged commit e6d12b3 into master May 22, 2018
@alexeyklyukin alexeyklyukin deleted the continue_on_delete_errors branch May 22, 2018 08:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants