-
Notifications
You must be signed in to change notification settings - Fork 1.2k
⚠️ Migration to the new events API #3262
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
base: main
Are you sure you want to change the base?
Conversation
Signed-off-by: Borja Clemente <[email protected]>
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: clebs The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Hi @clebs. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
Open Items:
|
/ok-to-test |
@clebs: The following tests failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
Signed-off-by: Borja Clemente <[email protected]>
Signed-off-by: Borja Clemente <[email protected]>
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.
two questions
pkg/recorder/recorder.go
Outdated
"k8s.io/client-go/tools/record" | ||
) | ||
|
||
// Provider knows how to generate new event recorders with given name. | ||
type Provider interface { | ||
// NewRecorder returns an EventRecorder with given name. | ||
GetEventRecorderFor(name string) record.EventRecorder | ||
GetEventRecorder(name string) events.EventRecorder |
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.
Why rename this?
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.
It was suggested by Stefan here #2141 (comment)
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 think that suggestion was to aid in making this a non-breaking change
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 interpreted it as a general suggestion, my bad. I will revert that change.
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.
Ah yeah. I only meant if we introduce another func, might as well improve the name
pkg/recorder/recorder.go
Outdated
GetEventRecorder(name string) events.EventRecorder | ||
// GetOldEventRecorder returns an EventRecorder for the old events API. | ||
// The old API is not 100% supported anymore, use the new one whenever possible. | ||
GetOldEventRecorder(name string) record.EventRecorder |
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.
Rather than extending the interface here, would it be possible to build a wrapper that makes a record.EventRecorder
out of a events.EventRecorder
?
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.
Yes, it is already built as a wrapper under the hood in intrec
. I added it here with the idea to support both APIs for some time. If it is not what we are going for, having the wrapper only where it is needed is better.
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 think there are two main ways we could go about this:
- We make this a non-breaking change by keeping the existing
GetEventRecorderFor
with the existing signature and add a newGetEventRecorder
with the newevents.EventRecorder
as return but mark theGetEventRecorderFor
as// deprecated
. At some point in a future release we will then removeGetEventRecorderFor
- We make this a breaking change by changing the signature of the existing
GetEventRecorderFor
to return anevents.EventRecorder
and we provide an adapter somewhere to go fromevents.EventRecorder
to arecord.EventRecorder
for places like the leader election
My vote if this is possible would be to do 1) as this is the least disruptive for c-r users but its possible I've missed something and it isn't possible
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.
Option 1 is doable, but I have to see if the wrapper approach is good enough. Reason being, that the wrapper calls the new API under the hood and both APIs are quite different. The old API has AnnotatedEventf
while the new one does not and the new one has things like relatedObject
and action
.
Otherwise, the other way to support both is having 2 distinct implementations in separate packages and duplicate the broadcaster, provider, interfaces and injection at the manager and cluster levels.
Finally also duplicate the tests so both versions are covered.
I will test if the wrapper is viable, present the results and then we can make an informed decision.
Signed-off-by: Borja Clemente <[email protected]>
The StartEventWatcher call is no longer needed since calling StartRecordingToSink already sets up a watcher and manages it via its context. Signed-off-by: Borja Clemente <[email protected]>
Signed-off-by: Borja Clemente <[email protected]>
} | ||
l.prov.lock.RUnlock() | ||
func (l *oldRecorder) Event(object runtime.Object, eventtype, reason, message string) { | ||
l.newRecorder.Eventf(object, nil, eventtype, reason, "unsupported", message) |
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 think here a less "intimidating" wording could be used? like "no action" instead of "unsupported" maybe?
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.
Sounds good to me, will change it.
PR needs rebase. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
This Pull Request migrates from the old events API (
k8s.io/client-go/tools/record
) to the new API (k8s.io/client-go/tools/events
).Closes #2141