Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Making finalizer removal even more readable #1393

Merged
merged 2 commits into from
Mar 6, 2020

Conversation

zen-dog
Copy link
Contributor

@zen-dog zen-dog commented Mar 5, 2020

Signed-off-by: Aleksey Dukhovniy alex.dukhovniy@googlemail.com

Co-Authored-By: Andreas Neumann aneumann@mesosphere.com
Co-Authored-By: Ken Sipe kensipe@gmail.com

Signed-off-by: Aleksey Dukhovniy <alex.dukhovniy@googlemail.com>
@@ -295,7 +292,7 @@ func updateInstance(instance *kudov1beta1.Instance, oldInstance *kudov1beta1.Ins
// if k8s GC was fast and managed to removed the instance (after the above Update removed the finalizer), we get an untyped
// "StorageError" telling us that the sub-resource couldn't be modified. We ignore the error (but log it just in case).
// historically we checked with a kerrors.IsNotFound() which failed based on the StorageError. Perhaps this is a k8s bug?
if isInstanceDeleted {
if instance.IsDeleting() && finalizerRemoved {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what if the instance does not have cleanup plan, thus does not have finalizer? The previous case still fallen in here, the new does not.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lol, you're right 😂 I feel like tryRemoveFinalizer needs an overhaul because we're trying to work around its quirks. I'm looking at it even closer and this else statement is actually not true!:

if planStatus := i.PlanStatus(v1beta1.CleanupPlanName); planStatus != nil {
    ...
}
else {
    // We have a finalizer but no cleanup plan. This could be due to an updated instance.
    // Let's remove the finalizer.
    ...
    return true
}

We're in fact not checking the existence of a plan, but only the existence of the according PlanStatus. And it is initialized in the middle of controller reconciliation while this method might be called even before that (or even in the webhook)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this feels like a lot of assumptions and hoop jumping... couldn't we just check the type of the err for the StorageError?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only with string compare, AFAIR. It's an error that's not wrapped as a nice typed error :-/

Signed-off-by: Aleksey Dukhovniy <alex.dukhovniy@googlemail.com>
Copy link
Member

@kensipe kensipe left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

Copy link
Member

@kensipe kensipe left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

@kensipe kensipe merged commit 9a84b71 into master Mar 6, 2020
@kensipe kensipe deleted the ad/yet-another-finalizer-fix branch March 6, 2020 16:40
runyontr pushed a commit that referenced this pull request Mar 11, 2020
Co-Authored-By: Ken Sipe <kensipe@gmail.com>
Co-Authored-By: Andreas Neumann <aneumann@mesosphere.com>
Signed-off-by: Aleksey Dukhovniy <alex.dukhovniy@googlemail.com>

Signed-off-by: Thomas Runyon <runyontr@gmail.com>
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.

None yet

4 participants