Artur Ferfecki

@gusfcarvalho you mentioned that we can add a `processGenerators` typo of flag to the values to instruct the controller to skip processing the generators. I see the [`root.go`](https://github.com/external-secrets/external-secrets/blob/main/cmd/controller/root.go#L209) implements this...

I kept the `createClusterGenerator: true`. Not sure if that flag was supposed to be merged with the new `createGenerators` flag.

I think the CRD permission should be limited to the external-secrets resources. It feels wrong to give it access to every CRD in the cluster. But I am no Kubernetes...

Hi @gusfcarvalho thanks for the comment. If I understand it correctly, the problem would appear if users would skip the installation of the generator CRDs but specified `spec.dataFrom.[0].sourceRef.generatorRef` in `ExternalSecret`...

I will try to attend the next community meeting (21st of May) 🙂.

@stohrendorf we run DT in Kubernetes. I restarted the frontend and backend workloads but the external references did not show up.

what does it mean that they are not persisted at all? Is that so that any change to the project will remove the external references?

@stohrendorf I run a sync job which updates external references for every project in DT using the DT api. As long as I don't upload new sbom the external reference...