Only remove the cleanup finalizer if the cleanup succeeds#7286
Conversation
0470fa7 to
41f5ebc
Compare
41f5ebc to
95eeab9
Compare
SgtCoDFish
left a comment
There was a problem hiding this comment.
Most of this looks pretty self explanatory and makes sense. Just one question from me before I'd feel comfortable merging!
| solver, err := c.solverFor(ch.Spec.Type) | ||
| if err != nil { | ||
| log.Error(err, "error getting solver for challenge") | ||
| return nil |
There was a problem hiding this comment.
question: Previously we swallowed the error and returned nil. Same in the if err := solver.CleanUp(ctx, ch); err != nil block below.
What's the motivation for the change to now start returning the error here (and below)? What effect will it have?
There was a problem hiding this comment.
There are two situations in which a cleanup is performed:
acme.IsFinalState(ch.Status.State)!ch.DeletionTimestamp.IsZero()
The old code swallowed errors when !ch.DeletionTimestamp.IsZero() but returned errors when acme.IsFinalState(ch.Status.State). So this change will only affect the first case.
In that case, the deletion of the challenge resource will be blocked until the handleFinalizer is successful. An error will be returned if something went wrong and the CleanUp function will be retried.
The previous behavior for the first case was that the CleanUp function was called once and the error was only logged and the finalizer deleted unconditionally.
There was a problem hiding this comment.
🤔 I just found there is a counter-issue: #7234
Challenges that are stuck in their cleanup phase: cleanup is failing and the resource is not being deleted...
There was a problem hiding this comment.
@erikgb convinced me that we should still move forward. I updated the PR.
|
/hold |
|
Issues go stale after 90d of inactivity. |
|
Stale issues rot after 30d of inactivity. |
95eeab9 to
9755045
Compare
|
Looks like issue #7234 will be solved in a different manner: #7234 (comment) I think we are able to move forward with this PR. /unhold |
9755045 to
3aca768
Compare
3aca768 to
2c7db23
Compare
Signed-off-by: Tim Ramlot <42113979+inteon@users.noreply.github.com>
2c7db23 to
0a5bab8
Compare
| Delete(cmacme.ACMEDomainQualifiedFinalizer, cmacme.ACMELegacyFinalizer) | ||
| return len(finalizers) > 0 | ||
| finalizers := sets.New(ch.Finalizers...) | ||
| return !finalizers.Has(cmacme.ACMELegacyFinalizer) && !finalizers.Has(cmacme.ACMEDomainQualifiedFinalizer) |
There was a problem hiding this comment.
| return !finalizers.Has(cmacme.ACMELegacyFinalizer) && !finalizers.Has(cmacme.ACMEDomainQualifiedFinalizer) | |
| return !finalizers.Has(cmacme.ACMEDomainQualifiedFinalizer) |
I think this is clearer, as we require all challenges to have the new finalizer.
There was a problem hiding this comment.
This function is called in two places:
- https://github.com/cert-manager/cert-manager/pull/7286/changes#diff-e9636826ce57cc3a7988b9d27b475a40c79c97a21eb80ba392dc9f137f770004R115 - Here, there will never be a legacy finalizer (since we drop it a few lines above)
- https://github.com/cert-manager/cert-manager/pull/7286/changes#diff-e9636826ce57cc3a7988b9d27b475a40c79c97a21eb80ba392dc9f137f770004R296 - Here, we want to also cleanup in case we only have a legacy finalizer.
So, I do think that is makes sense to check for both to make sure we cleanup in the second case.
There was a problem hiding this comment.
True, but the naming is confusing here. Have to look at the "surroundings" to understand how this works. But we can leave this for an eventual follow-up.
There was a problem hiding this comment.
Yes, let's leave the name for now. I already reverted the name change I wanted to make.
| gen.DefaultTestNamespace, | ||
| gen.ChallengeFrom(deletedChallenge, | ||
| gen.SetChallengeProcessing(true), | ||
| gen.SetChallengeProcessing(false), |
There was a problem hiding this comment.
Is this change expected? Processing is part of the status subresource. This action should only assert that the finalizers are removed.
|
/approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: inteon The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/retest |
|
@inteon: The following tests failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
|
/retest |
This addresses two problems:
acme.IsFinalStateblock, but in the former, the Status.Processing and Status.Presented fields were not being reset and in the latter case, the finalizer wasn't being removed if the cleanup succeeded.Part of:
supersedes #5126
Kind
/kind cleanup
Release Note