kapp-controller
kapp-controller copied to clipboard
carvel-dev
retry removing finalizer from app cr
Describe the problem/challenge you have
faced with following error: Delete failed: Unblocking for deploy: Updating app: Operation cannot be fulfilled on apps.kappctrl.k14s.io "xxx": the object has been modified; please apply your changes to the latest version and try again
Describe the solution you'd like lets put in a retry behaviour for finalizer removal for both pkgr and app.
Vote on this request
This is an invitation to the community to vote on issues, to help us prioritize our backlog. Use the "smiley face" up to the right of this comment to vote.
👍 "I would like to see this addressed as soon as possible" 👎 "There are other more important things to focus on right now"
We are also happy to receive and review Pull Requests if you want to help working on this issue.
Delete failed: Unblocking for deploy: Updating app: Operation cannot be fulfilled on apps.kappctrl.k14s.io "xxx": the object has been modified; please apply your changes to the latest version and try again
Do we have any details on how to reproduce this error?
lets put in a retry behaviour for finalizer removal for both pkgr and app.
We should always retry, or is there a way to isolate this to a specific case?
For the App CR, the finalizer removal func is located here: https://github.com/vmware-tanzu/carvel-kapp-controller/blob/4b0307d377e429c00d8f5cf6499bf59989f71f44/pkg/app/crd_app.go#L63
For the PackageRepository, the finalizer removal func is here: https://github.com/vmware-tanzu/carvel-kapp-controller/blob/f30b42e0cbeb72e3b29f50a496abbc956c35c5de/pkg/pkgrepository/crd_app.go#L60
Do we have any details on how to reproduce this error?
i dont have any specific repro scenarios (i was just deleting a package that installed other packages). i imagine it's either kapp-controller doing some updates, or just some other controller.
We should always retry, or is there a way to isolate this to a specific case?
i think we should be able to isolate retry logic just for unblock* methods.
I think it would still be worthwhile to identify a way to consistently reproduce this. Any further thoughts you can provide on this would help.
i think we should be able to isolate retry logic just for unblock* methods.
Sounds reasonable to me though.