Problem description
Creating Events via a record.EventRecorder does not work in combination with a fake ClientSet.
The generated error message is:
'Server rejected event '&v1.Event{...}': request namespace does not match object namespace, request: "" object: "test"' (will not retry!)
How to reproduce
package main
import (
"flag"
"time"
"github.com/golang/glog"
corev1 "k8s.io/api/core/v1"
metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
"k8s.io/client-go/kubernetes/fake"
"k8s.io/client-go/kubernetes/scheme"
clientcorev1 "k8s.io/client-go/kubernetes/typed/core/v1"
"k8s.io/client-go/tools/record"
)
func main() {
flag.Parse()
pod := &corev1.Pod{
ObjectMeta: metav1.ObjectMeta{
Namespace: "test",
Name: "dummy",
SelfLink: "/api/v1/namespaces/test/pods/dummy",
},
}
cli := fake.NewSimpleClientset(pod)
eventSink := &clientcorev1.EventSinkImpl{
cli.CoreV1().Events(corev1.NamespaceAll),
}
eventBroadcaster := record.NewBroadcaster()
eventBroadcaster.StartLogging(glog.V(3).Infof)
eventBroadcaster.StartRecordingToSink(eventSink)
r := eventBroadcaster.NewRecorder(scheme.Scheme, corev1.EventSource{Component: "test"})
r.Event(pod, corev1.EventTypeNormal, "SomeReason", "Dummy event")
time.Sleep(time.Second)
}
Investigation
At fake/fake_event_expansion.go#L27, core.NewRootCreateAction() returns an action without Namespace:
x/vendor/k8s.io/client-go/testing.CreateActionImpl {
ActionImpl: x/vendor/k8s.io/client-go/testing.ActionImpl {
Namespace: "",
Verb: "create",
Resource: (*x/vendor/k8s.io/apimachinery/pkg/runtime/schema.GroupVersionResource)(0xc0000f5a58),
Subresource: "",},
Name: "",
Object: x/vendor/k8s.io/apimachinery/pkg/runtime.Object(*x/vendor/k8s.io/api/core/v1.Event) *{
...
Reason: "SuccessfulCreate",
Message: "Dummy event",
...},}
Later, inside c.Fake.Invokes(), the action is handled, but because ns != obj.Namespace an error is returned.
Note: using cli.CoreV1().Events("test") to create the EventSinkImpl suppresses the error, but then a call to List() shows no item.
I've started looking into this issue and now have a PR with a test that reproduces it at kubernetes/kubernetes#70343. It does not yet include the fix because it seems like the proper way to address this may require some significant changes to k8s.io/client-go/kubernetes/fake. If the possible solution I've suggested is approved, it will fix this issue.
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten
Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close
@fejta-bot: Closing this issue.
In response to this:
Rotten issues close after 30d of inactivity.
Reopen the issue with/reopen.
Mark the issue as fresh with/remove-lifecycle rotten.Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close
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/test-infra repository.
Most helpful comment
I've started looking into this issue and now have a PR with a test that reproduces it at kubernetes/kubernetes#70343. It does not yet include the fix because it seems like the proper way to address this may require some significant changes to
k8s.io/client-go/kubernetes/fake. If the possible solution I've suggested is approved, it will fix this issue.