Create structs for ui objects in kueue-viz instead of ad-hoc objects

[akram]

What would you like to be cleaned: In most backend functions, ad-hoc objects are created to convey data from the kube api to the websocket layer. This was done for several reasons:

• forwarding directly the kubernetes objects would have been too heavy as most of the fields are not used on the ui side
• the dashboard is, currently, a read-only view of aggregated data from the kubernetes api, so, it would not have been necessary to convey kubernetes data back for saving (for example)
• the sake of quick development

Why is this needed: It could be interesting to have dedicated objects for this usage for better debuggability, especially on the client side, and to ensure data consistency.

As a first pass, we can create structs manually based on the existing ad-hoc objects. But, if we can find a way to generate them later it could be more efficient.

[akram]

/kind dashboard

[akram]

@tenzen-y we have discussed privately yesterday the requirement to have a protobuf API for keueviz-backend. Do you think you can elaborate here on the requirement? Maybe we can rename this issue also if it the same permimeter. wdyt ?

[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

[tenzen-y]

@tenzen-y we have discussed privately yesterday the requirement to have a protobuf API for keueviz-backend. Do you think you can elaborate here on the requirement? Maybe we can rename this issue also if it the same permimeter. wdyt ?

Thank you for raising this issue based on our discussion. My recommendation is to have a dashboard server-side dedicated protocol-buffers to avoid dependencies for Kueue CRD. In the first dashboard implementation step, depending on Kueue CRD makes sense since it could realize the rapid implementation and deliver dashboard features to users.

However, in the long term, I assume that the dashboard wants to have a dedicated API to avoid server-side response construction every time, and we want to avoid expanding CRD only for the dashboard.

[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

[k8s-triage-robot]

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:

• 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 rotten
• Close this issue with /close
• Offer to help out with Issue Triage

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

/lifecycle rotten