[SURE-7365?] Update status fields to provide what UI needs for "resourceCount"

[manno]

Background

The old key BundleStatus.ResourceKey https://fleet.rancher.io/ref-crds#resourcekey works like this:

ResourceKey lists resources, which will likely be deployed. The actual list of resources on a cluster might differ, depending on the helm chart, value templating, etc..

The sum of all resources in bundles is stored in the GitRepo. This seems to multiply the estimate.

We want to use the accurate resource lists and counts. The BundleDeploymentStatus.Resources lists the actual deployed resources from Helm:

Resources lists the metadata of resources that were deployed according to the helm release history.

Open Questions

• [ ] what views in the UI use the resource list? what makes sense?
  • 1 gitrepo -> n bundles -> n clusters
  • resources per cluster
  • resources per gitrepo
• [x] can the UI use bundledeployment.status.resources directly? - It does.
• [ ] is there a view for resources/bundles of a gitrepo per cluster?
• [ ] should work bundlenamespacemapping

Possible Follow Ups:

• document meaning of conditions. Is "Active" a failure state?
• remove helm template fleet controller in a later release (like 2.10)

TODO

• [x] populate gitrepo.status.resources from bundledeployment.status.resources instead, see fromResourceKey. PR #2523
• [x] bundle.status.resourceKey is still computed from helm template, for compatibility. We need to check if UI dashboard uses this. Once it's no longer used, we can stop populating the field and remove helm template.
• [x] status derived from new bundledeployment.status.resources in bundle reconciler PR #2535
• ~[x] status derived from new resources key in gitrepo reconciler~
• ~[x] resource count calculation in cluster reconciler~
• ~[x] resource count calculation in clustergroup reconciler?~
• ~[x] deprecate resourceKey and related outdated status fields~

Also see:

• https://github.com/rancher/fleet/issues/1101

[manno]

This is how the resource list is propagated:

[rubhanazeem]

Additional QA

To address this issue we merged two PR's

1. Populate bundle status resources from bundleDeployment status resources
2. Use bundleDeployment to store resources in gitRepo status

Problem

1. We aim to utilize precise resource lists and counts. Previously, in bundles, we set status.ResourceKey by running a Helm template, which did not provide the actual resources. With the refactoring introduced in the attached PRs, we now rely on the actual resources from bundle deployments, and bundle.status.ResourceKey is derived from these deployments.

2. A similar issue existed with gitRepos, as described in point 1. Now, gitRepos also populate gitrepo.status.Resources based on actual bundle deployments.

Solution

These PRs introduced refactoring that modifies gitRepos so that gitrepo.status.Resources is now populated from bundle deployments instead of bundles. Similarly, the refactoring for bundles ensures that bundle.status.ResourceKey is populated from bundle deployments rather than by running Helm templates.

Testing

This is primarily refactoring and should not alter any behavior in Fleet.

Engineering Testing

Manual Testing

We need to confirm that bundle.status.ResourceKey has correct values, as well as gitrepo.status.Resources.

Automated Testing

We have some integration and e2e tests to check this.

[mmartin24]

Test environment

Rancher v2.9-d2fa8a7d6116c48a814ee7983af522d614461e49-head with Fleet 104.0.0+up0.10.0-rc.19 Single cluster k3s with v1.28.8+k3s1

---

Tests done

Check 1 - Verified Clusters Ready and Resources fields contain all info expected on multiple Gitrepos

Check 2 - Bundles, Resources and Conditions are correctly populated on UI:

Check 3 - Verified bundle.status.ResourceKey and gitrepo.status.Resources have correct values

Bundles Resources for fleet-62

```yaml k describe -n fleet-local bundles.fleet.cattle.io fleet-62-simple | tail -32 Resource Key: API Version: apps/v1 Kind: Deployment Name: frontend Namespace: default API Version: apps/v1 Kind: Deployment Name: redis-master Namespace: default API Version: apps/v1 Kind: Deployment Name: redis-slave Namespace: default API Version: v1 Kind: Service Name: frontend Namespace: default API Version: v1 Kind: Service Name: redis-master Namespace: default API Version: v1 Kind: Service Name: redis-slave Namespace: default resourcesSha256Sum: e388bede70f9b5f283bc28540505af63e40d1a7b68bdc771220c3cdb18419b39 Summary: Desired Ready: 1 Ready: 1 Unavailable: 0 Unavailable Partitions: 0 Events: ```

Bundlesdeployments Resources for fleet-62

```yaml k describe bundledeployments.fleet.cattle.io -n cluster-fleet-local-local-1a3d67d0a899 | tail -33 Resources: API Version: apps/v1 Created At: 2024-07-08T10:33:49Z Kind: Deployment Name: frontend Namespace: default API Version: apps/v1 Created At: 2024-07-08T10:33:49Z Kind: Deployment Name: redis-master Namespace: default API Version: apps/v1 Created At: 2024-07-08T10:33:49Z Kind: Deployment Name: redis-slave Namespace: default API Version: v1 Created At: 2024-07-08T10:33:49Z Kind: Service Name: frontend Namespace: default API Version: v1 Created At: 2024-07-08T10:33:49Z Kind: Service Name: redis-master Namespace: default API Version: v1 Created At: 2024-07-08T10:33:49Z Kind: Service Name: redis-slave Namespace: default Sync Generation: 6 Events: ```

Gitrepo status resources for fleet-62

```yaml k describe gitrepos.fleet.cattle.io -n fleet-local fleet-62 | tail -48 Resources: API Version: apps/v1 Id: default/frontend Kind: Deployment Name: frontend Namespace: default State: Ready Type: apps.deployment API Version: apps/v1 Id: default/redis-master Kind: Deployment Name: redis-master Namespace: default State: Ready Type: apps.deployment API Version: apps/v1 Id: default/redis-slave Kind: Deployment Name: redis-slave Namespace: default State: Ready Type: apps.deployment API Version: v1 Id: default/frontend Kind: Service Name: frontend Namespace: default State: Ready Type: service API Version: v1 Id: default/redis-master Kind: Service Name: redis-master Namespace: default State: Ready Type: service API Version: v1 Id: default/redis-slave Kind: Service Name: redis-slave Namespace: default State: Ready Type: service Summary: Desired Ready: 1 Ready: 1 Update Generation: 6 ```

---

Looking good to me.
@manno , before closing this item I just wanted to ask if we are ok with the open questions unchecked above or if there is need to be reviewed. Thank you.

[mmartin24]

Commented with the team. Agreed general testing is ok and note to due later checking with Clusters and Cluster Groups. Closing issue.