-
Notifications
You must be signed in to change notification settings - Fork 551
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
Fix finalizer processing #3180
Fix finalizer processing #3180
Conversation
/hold |
This is an improvement, but it's not perfect... there's still a race condition. |
941887a
to
127d7ed
Compare
/unhold |
127d7ed
to
aaed167
Compare
There are two reconcilers for the CSV, one is controller-runtime based, the other is based on queueinformer. A finalizer was added to the CSV and it's handled by the controller-runtime reconciler. However, the queueinformer-based reconciler may take a while to do its processing such that the CSV may be deleted and the finalizer run via the controller-runtime reconciler. (This still takes <1s.) This causes problems when CSV being synced is deleted. The queueinformer attempts to sync RBAC to the stale CSV. The proper (BIG/risky) fix is to consolidate the two reconcilers. A less risky fix is to move the finalizer to the queueinformer reconciler and query the lister cache to see if the CSV has been deleted, and not do the RBAC updates if that's the case. Signed-off-by: Todd Short <[email protected]>
aaed167
to
a237f2f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had a question and two nits, otherwise this looks good to me.
@@ -1093,6 +1095,9 @@ func (a *Operator) handleClusterServiceVersionDeletion(obj interface{}) { | |||
"phase": clusterServiceVersion.Status.Phase, | |||
}) | |||
|
|||
logger.Debug("start deleting CSV") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need these?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They are useful in tracking what's happening; this one is debug, so it doesn't clutter the log normally.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you asking me to get rid of the extra logs?
return nil, false | ||
} | ||
|
||
log.Info("started finalizer") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same question
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This one is Info, however.
@@ -100,10 +95,6 @@ func (r *OperatorConditionGeneratorReconciler) Reconcile(ctx context.Context, re | |||
return ctrl.Result{}, client.IgnoreNotFound(err) | |||
} | |||
|
|||
if err, ok := r.processFinalizer(ctx, in); !ok { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you know why we were doing this here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At the time, it was the easier location to put the finalizer, since it was the controller-runtime reconciler. But that reconciler didn't manage the RBAC, which caused this race condition. Moving it to the queueinformer reconciler is the proper place for it. It's easier than combining the reconcilers.
ping @kevinrizza ? |
/approve |
fc3c183
Description of the change:
Handle CSV deletion during sync.
Motivation for the change:
There are two reconcilers for the CSV, one is controller-runtime based,
the other is based on queueinformer. A finalizer was added to the CSV
and it's handled by the controller-runtime reconciler.
However, the queueinformer-based reconciler may take a while to do its
processing such that the CSV may be deleted and the finalizer run via
the controller-runtime reconciler. (This still takes <1s.)
This causes problems when CSV being synced is deleted. The queueinformer
attempts to sync RBAC to the stale CSV. The proper (BIG/risky) fix is to
consolidate the two reconcilers. A less risky fix is to query the lister
cache to see if the CSV has been deleted (or has a DeletionTimestamp),
and not do the RBAC updates if that's the case.
Architectural changes:
None.
Testing remarks:
Reviewer Checklist
/doc
[FLAKE]
are truly flaky and have an issue