Open wolffberg opened 3 weeks ago
The whole point of a cluster wide secret for CHAP was that it needs to exist prior to installing the Chart. I agree this pre-install-hook isn't the prettiest solution but fail to understand you can't reverse the order in your workflow?
When deploying the hpe-csi-driver chart using a multi source Argo CD application where the first source is the hpe-csi-driver chart and the second source is a custom chart with the secret containing the
iscsi.chapSecretName
secret, Argo CD cannot deploy the charts and fails withInstead of using a custom pre-install-hook I suggest using a Kubernetes native way of ensuring the secret is available and correct.
This could for example be mounting the secret into the container and validating it using an init container.