Closed joyantamishu closed 6 months ago
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
This bot triages issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/reopen
/remove-lifecycle rotten
Please send feedback to sig-contributor-experience at kubernetes/community.
/close not-planned
@k8s-triage-robot: Closing this issue, marking it as "Not Planned".
Hello All,
I am referring this code and line https://github.com/kubernetes/kubernetes/blob/master/test/integration/events/events_test.go#L76
First I would like to thank to author for adding this example. This piece of code is really helpful to develop more complicated solution based on k8s go-client. But I have few questions, which arises when we go for the more complicated event posting mechanism.
So, why polling? In a limited resource environment, when we try to send multiple events, and poll for every request, the static value 100 and 20 might not be effective, considering the load on api-server. Persistence of the sent event might take longer. Now we can argue some 99 percentile would follow this pattern, but that is not the answer. This is non-deterministic and theoretically the timeout can exceed whatever the value we set. So my question is, Can we somehow modify the example so that instead of polling, some interrupt based mechanism would notify the caller that event has been handled to api-server for processing. I am not familiar with the go-client code that much, so I am not sure if there is any existing method/packages in go-client that can perform this for me.
Thanks in advance.