Workloads status component for resource list components

[ajatprabha]

This PR adds workloads status section charts to the resource list components.
Works towards #3440

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: ajatprabha
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: pewu

If they are not already assigned, you can assign the PR to them by writing /assign @pewu in a comment when ready.

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[jeefy]

Have you rebased to master recently? There are some files/changes in there I know have been removed as of the Angular migration in this PR. Totally get it's a WIP, just looking to help out. 😄

Thanks!

[ajatprabha]

Yes, I rebased with master before creating the PR. The changes are working fine locally. Can you point out the files that need attention, I'll make the necessary changes after I add the statuses for workloads.

[maciaszczykm]

Pointed a few places, please review all of your changes or cherry pick your commits into the new branch created from current master.

[codecov]

Codecov Report

Merging #3637 into master will decrease coverage by 0.02%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #3637      +/-   ##
==========================================
- Coverage   46.81%   46.78%   -0.03%     
==========================================
  Files         165      165              
  Lines        7763     7763              
  Branches       24       24              
==========================================
- Hits         3634     3632       -2     
- Misses       3907     3910       +3     
+ Partials      222      221       -1

Impacted Files	Coverage Δ
src/app/backend/sync/secret.go	70.29% <0%> (-2.98%)	⬇️
...p/backend/integration/metric/common/aggregation.go	90.9% <0%> (+1.81%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 6edc1da...d9ca979. Read the comment docs.

[ajatprabha]

As discussed on Slack, I have added the status bar on each list component. This allowed using existing data in the component as suggested by @maciaszczykm. cc: @jeefy

[jeefy]

I tested this and things look good.

@ajatprabha Is this still considered a WIP? Or is this PR ready for review?

[ajatprabha]

I was thinking to also add PodList.cumulativeMetrics to this PR. I'll open a new PR for that and remove WIP from this one.

[floreks]

IMHO adding a status bar on top of every list makes everything a bit overwhelming. Lists should be clean and contain only key information about the objects. Adding such bars might distract the user. I'd stick to the original charts at the top of the page to show statuses. List itself already contains status for every object. We should not need any more indicators to keep it as simple and clean as possible.

[maciaszczykm]

I generally like the idea of having additional information next to the lists but I think we could use other design here. At the moment it doesn't match the styling of the rest of the component, is a bit too bold and colors are a bit overwhelming. We could use the help of someone who knows more than us about design, @danielromlein do you have some time for it?

I think we will still need a component to display statuses of all workloads in one place. This (in each card) might be some feature enabled in the settings once we will style it. Both have their advantages, one is easier to reach, the second gives a better overview.

Additionally like @floreks noticed we have a lot of things in the card components, we have to be careful here.

[ajatprabha]

I had the same thought as @floreks while implementing this.

How do I pull data for a central component from backend then? Suggestions would be helpful. A new endpoint in the backend or maybe get it from state?

[maciaszczykm]

Is calling all workload endpoints an option? Then we can send multiple calls asynchronously and display graphs when the responses come.

[ajatprabha]

We'll be replicating calls that way. Maybe we can use ViewChild to get data from list component or use Output?

Is there a Service which manages this data from backend? I think component calls the endpoint itself right now.
I know about the EndpointManager but that only provides endpoints right?

[maciaszczykm]

I know, output was the thing that I was mentioning before on Slack. The problem with this is coupling components. With separate calls it is independent. @floreks WDYT?

[floreks]

How about adding emitter to the list and emit data on list update? This way we could avoid hard coupling and other components that require similar data could easily subscribe to it. I don't remember exactly how backend looked like before. I'd have to check it.

[maciaszczykm]

@floreks We had group resources, i.e. workloads, overview, config etc.

[ajatprabha]

Closing in favour of #3667