[GarbageCollector] monitor the watch latency #30483
Conversation
|
GCE e2e build/test passed for commit b1a45b0. |
| if err != nil { | ||
| utilruntime.HandleError(fmt.Errorf("Error syncing item %#v: %v", key, err)) | ||
| // retry if garbage collection of an object failed. | ||
| gc.dirtyQueue.AddWithTimestamp(key, start) |
There was a problem hiding this comment.
This is noise. I can separate it to another PR if you think the change is not obvious.
|
@caesarxuchao PR needs rebase |
|
This PR can wait after 1.4 release. |
|
Can one of the admins verify that this patch is reasonable to test? If so, please reply "ok to test". This message will repeat several times in short succession due to jenkinsci/ghprb-plugin#292. Sorry. |
Automatic merge from submit-queue [GarbageCollector] GC retries failed garbage collection The code was buried in #30483, which we decided to put off to 1.5.
|
@caesarxuchao @lavalamp @gmarek Do we need this for 1.5? (I see a 1.5 milestone) |
|
Removed. Thanks for the reminder. |
|
[APPROVALNOTIFIER] Needs approval from an approver in each of these OWNERS Files: We suggest the following people: |
|
@caesarxuchao - can we close this, or are we going to continue working on it? |
|
Closed. Thanks for the reminder. |
Added a metric for the latency between when the GC sends a deletion request and when the deletion is observed by the GC again. This is the upper bound of the latency of watch, the latency between when apiserver commits a change and when the GC observes the change via watch, which is an interesting metric because we want to know if the race condition of orphaning described in #26120 is a real concern.
This change is