operator: always report events #9427
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
10 tasks
yuvalif
reviewed
Dec 15, 2021
| @@ -51,7 +51,7 @@ func ReportReconcileResult(logger *capnslog.PackageLogger, recorder *k8sutil.Eve | |||
| logger.Errorf("failed to reconcile %s %q. %v", kind, nsName, err) | |||
|
|
|||
| // 2. event | |||
| recorder.ReportIfNotPresent(obj, corev1.EventTypeWarning, string(cephv1.ReconcileFailed), err.Error()) | |||
| recorder.Event(obj, corev1.EventTypeWarning, string(cephv1.ReconcileFailed), err.Error()) | |||
There was a problem hiding this comment.
if this is happening on every retry, maybe we should keep the ReportIfNotPresent() call?
There was a problem hiding this comment.
If there are multiple events, they will be collated together like so, with something similar to (x4 over 8m46s) indicating that they have happened multiple times and without adding loads of clutter:
Warning ReconcileFailed 8m11s rook-ceph-object-controller failed to create object store deployments: fail
ed to start rgw health checker for CephObjectStore "rook-ceph/my-store", will re-reconcile: failed to create bucket checker for
CephObjectStore "rook-ceph/my-store": failed to create or retrieve rgw admin ops user: failed to create object user "rgw-admin
-ops-user". error code 1 for object store "my-store": failed to create s3 user. . : signal: interrupt
Normal ReconcileSucceeded 9s (x4 over 8m46s) rook-ceph-object-controller successfully configured CephObjectStore "rook-c
eph/my-store"
IMO, that is an okay trade-off for getting more insight into when things have happened most recently.
There was a problem hiding this comment.
ok .so this is happening regardless of whether we use ReportIfNotPresent or Event?
I guess we can just rely on this mechanism instead of adding another one.
The original PR which added event reporting unnecessarily "optimized" to prevent spamming the API controller[1]. It is sometimes important to get events as they happen and not hide new events behind preexisting older events. For example, in integration tests, we may often want to wait for a controller to finish processing an update, and the best way to do that is to wait for the "ReconcileSucceeded" event. In order for this to be useful, the events must be reported each time. If we begin having problems with events being reported too often, then we should fix the underlying issue of reconciles happening too often instead of relying on a time-based "optimization" that hides recent event reports that may be useful. [1]: rook#7222 Signed-off-by: Blaine Gardner <blaine.gardner@redhat.com>
BlaineEXE
force-pushed
the
always-report-reconcile-events
branch
from
59259d3
to
da61ac1
Compare
leseb
approved these changes
Dec 17, 2021
mergify bot
added a commit
that referenced
this pull request
Dec 20, 2021
operator: always report events (backport #9427)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The original PR which added event reporting unnecessarily "optimized" to
prevent spamming the API controller1.
It is sometimes important to get events as they happen and not hide new
events behind preexisting older events. For example, in integration
tests, we may often want to wait for a controller to finish processing
an update, and the best way to do that is to wait for the
"ReconcileSucceeded" event. In order for this to be useful, the events
must be reported each time.
If we begin having problems with events being reported too often, then
we should fix the underlying issue of reconciles happening too often
instead of relying on a time-based "optimization" that hides recent
event reports that may be useful.
Signed-off-by: Blaine Gardner blaine.gardner@redhat.com
Description of your changes:
Which issue is resolved by this Pull Request:
Resolves #
Checklist:
make codegen) has been run to update object specifications, if necessary.