Switch to the new event recorder in Kueue

[achernevskii]

What would you like to be added:

#1387 (comment)

Switch from record.EventRecorder to events.EventRecorder, which has extra machine-readable fields.

https://github.com/kubernetes/client-go/blob/84a6fe7e4032ae1b8bc03b5208e771c5f7103549/tools/events/interfaces.go#L29

Why is this needed:

It will be useful to distinguish between a "regular" workload finish (when the job ends) versus another kind of failure, in a machine readable way.

Completion requirements:

This enhancement requires the following artifacts:

• Design doc
• API change
• Docs update

The artifacts should be linked in subsequent comments.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[tenzen-y]

/remove-lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[tenzen-y]

/remove-lifecycle stale

[vladikkuzn]

/assign

[mimowo]

It will be useful to distinguish between a "regular" workload finish (when the job ends) versus another kind of failure, in a machine readable way.

It is not clear to me if this motivation is still valid since we have the reason field indicating Failed / Succeeded since #2026. I would suggest to wait for a proper support of the new interface from the controller-runtime, re-opened the discussion in kubernetes-sigs/controller-runtime#2141.