Keep track of managed objects in `.status.inventory`

[stefanprodan]

Similar to Flux Kustomization, the HelmRelease should expose the managed objects in .status.inventory. This would improve the observability of Flux as right now users need to query the Helm storage, extract the tar.gz from the Secret value and iterate over the objects to list them. One major pain point with Helm storage lookup is that the managed objects don't have the namespace set, CRDs are missing, etc. The helm-controller knows which objects it applies, so we can generate an accurate inventory.

[matheuscscp]

The Flux CLI and other tools that traverse the resource tree can also benefit, no more .tar.gz processing anywhere.

[stealthybox]

would this also track resources such as upgrade hooks and tests in the same inventory list?
Just noting this should specifically use the output of post-renderers.

[matheuscscp]

This would reflect the rendered manifests you can find by opening up the helm storage secret

[stefanprodan]

This would reflect the rendered manifests you can find by opening up the helm storage secret

CRDs are not in the secret, but since we manage them unlike Helm, they should be in the inventory.

would this also track resources such as upgrade hooks and tests in the same inventory list?

These resources are ephemeral, both jobs and pods get removed after hook/test runs, so tracking them in the inventory would be wrong. Tests are already tracked in .status.history.

[matheuscscp]

CRDs are not in the secret, but since we manage them unlike Helm, they should be in the inventory.

Yep, with addition of the CRDs

[nagygergo]

I know we have some integration charts that have a couple thousand resources in them. Would it make sense to limit or truncate this list? Or with the inventory keeping pattern, the CR storage limit would be enough to fit both this, and .status.history in?

[stefanprodan]

The Flux inventory is very compact as it records just the kind/namespace/name. We have Kustomizations managing 10K and the CR size is very small

[Ashish7812]

@stefanprodan and @matheuscscp Can we also export the status field of some selected resources of the chart to the helm release status field?

A user can select which k8 resource status field to export via some annotation. This way if there is dependency between two helm releases then the dependent helm release can read the output and can use it in its own helm release as input value.

ex: Lets say in the helm release we have the following resource along with others

apiVersion: ec2.services.k8s.aws/v1alpha1
kind: VPC
metadata:
  name: tutorial-vpc-{{ .Release.Name }}
  annotations:
    output_vpcid: "$.status.vpcID" # Output this key in the status field
spec:
  cidrBlocks:
  - 10.0.0.0/16
  enableDNSSupport: true
  enableDNSHostnames: true
  tags:
    - key: name
      value: vpc-tutorial-{{ .Release.Name }}

The helm release can read the status field of the VPC resource and output the selected key.

[matheuscscp]

Can we also export the status field of some selected resources of the chart to the helm release status field?
A user can select which k8 resource status field to export via some annotation. This way if there is dependency between two helm releases then the dependent helm release can read the output and can use it in its own helm release as input value.

This is a completely new feature request, please open a separate issue for this. This issue is supposed to track only the implementation of .status.invetory like in the Kustomization API as it is today, simply exposing the inventory of k8s objects the HelmRelease manages. Furthermore, this would require an RFC in the flux2 repo, as the same could apply to the Kustomization API: it also applies things, has dependencies and post-build substitution variables.