Following the deprecation notice of the corev1.Events API I was migrating to eventsv1.Events. I discovered that controller-runtime logs in a way I find unexpected, here: https://github.com/clebs/controller-runtime/blob/137b9c03159a5a3314f9212159219a044a66933b/pkg/internal/recorder/recorder.go#L110-L132

Examining the logging of corev1.Event I find:

			func(e *corev1.Event) {
				p.logger.V(1).Info(e.Message, "type", e.Type, "object", e.InvolvedObject, "reason", e.Reason)
			})

Compare with the newer eventsv1.Event logging:

			e, isEvt := event.(*eventsv1.Event)
			if isEvt {
				p.logger.V(1).Info(e.Note, "type", e.Type, "object", e.Related, "action", e.Action, "reason", e.Reason)
			}

You see there that for "object" in old corev1.Events, it uses InvolvedObject. But for eventsv1.Events it uses RelatedObject.

Well in corev1, InvolvedObject is a ObjectReference: https://pkg.go.dev/k8s.io/api@v0.35.0/core/v1#Event

But in corev1 and eventsv1, Related is a *ObjectReference: https://pkg.go.dev/k8s.io/api@v0.35.0/events/v1#Event

Comparing the documentation & design of these two Events, it is my impression that "object" should be logged as eventsv1.Event#Regarding, not eventsv1.Event#Related. Related should be a separate key, e.g. "related": e.Related.

As it stands if I want to log the k8s object in my Events I have to duplicate the Regarding & Related fields or I'll see logs with "object": <nil>. But then when logr handles the e.Related field, it finds that the *ObjectReference doesn't implement a json marshaling methods, so it falls back to the Golang struct fmt which is ugly.

Looking at the godoc of eventsv1 Event:

	// regarding contains the object this Event is about. In most cases it's an Object reporting controller
	// implements, e.g. ReplicaSetController implements ReplicaSets and this event is emitted because
	// it acts on some changes in a ReplicaSet object.
	// +optional
	Regarding corev1.ObjectReference `json:"regarding,omitempty" protobuf:"bytes,8,opt,name=regarding"`

	// related is the optional secondary object for more complex actions. E.g. when regarding object triggers
	// a creation or deletion of related object.
	// +optional
	Related *corev1.ObjectReference `json:"related,omitempty" protobuf:"bytes,9,opt,name=related"`

Compare to corev1:

	// The object that this event is about.
	InvolvedObject ObjectReference `json:"involvedObject" protobuf:"bytes,2,opt,name=involvedObject"`

	// Optional secondary object for more complex actions.
	// +optional
	Related *ObjectReference `json:"related,omitempty" protobuf:"bytes,13,opt,name=related"`

Given all this, I feel a change is in order for the eventsv1.Event logging code to use "object": e.Regarding. Unless this would be considered a breaking change at this point. Would you be willing to accept a PR?