charts/csi-powermax: Migrate reverse proxy config from ConfigMap to Secret #608
Conversation
* remove mode from pmax config.yaml * remove mode from pmax config.yaml
This reverts commit 4f89c43.
lukeatdell
requested review from
gallacher,
tdawe,
alikdell,
atye,
hoppea2,
chaganti-rajitha,
coulof,
meggm,
niranjan-n1,
shaynafinocchiaro,
sharmilarama,
tssushma,
shanmydell,
baoy1,
YianZong,
forrestxia,
nitesh3108,
rajendraindukuri,
shefali-malhotra,
panigs7,
chimanjain and
HarishH-DELL
as code owners
| @@ -20,31 +20,50 @@ spec: | |||
| image: {{ required "Must provided an image for reverseproxy container." .Values.image }} | |||
| imagePullPolicy: Always | |||
| env: | |||
| {{- $useRevProxySecret := not (empty .Values.secretName) }} | |||
There was a problem hiding this comment.
Clever way to set this parameter without having to explicitly provide it in the values files.
There was a problem hiding this comment.
So, the caveat here is, if the user is using their old values file during an upgrade, which does not have secretName in it, the new csireverseproxy values file will provide the default value and try to deploy with the new secret.
As far as I was able to find, there isn't a way to avoid this behavior unless we set secretName: "" in the default csireverseproxy values file.
There was a problem hiding this comment.
You can use hasKey along with the current condition in the helm template to check if Values.secretName exists (https://helm.sh/docs/chart_template_guide/function_list/#haskey). Then it will still work even if they are using the old values file.
| @@ -1,7 +1,17 @@ | |||
| {{- /* | |||
| Deprecation notice: use of reverseproxy-config ConfigMap is deprecated and will | |||
There was a problem hiding this comment.
Nice use of deprecation comments throughout. Will help when we remove these parameters in a future release.
charts/csi-powermax/values.yaml
Outdated
| # Name of the reverseproxy secret as a Kubernetes resource. | ||
| # Default value: "powermax-reverseproxy-secret" | ||
| # Example: "powermax-reverseproxy-secret" | ||
| secretName: powermax-reverseproxy-secret |
There was a problem hiding this comment.
This value can be empty by default to support backwards compatibility with the ConfigMap. If a customer upgrades without creating a Secret, this will attempt to mount the Secret.
There was a problem hiding this comment.
ah yep. I just mentioned this in response to your comment above.
I was in favor of keeping it empty as well, but was unsure.
Will amend!
- update default value for secretName in both values files. - update secret-configMap switching logic to check for existing secretName key, for better backward compat.
| # PowerMax endpoints. | ||
| # Default value: "" | ||
| # Example: "powermax-reverseproxy-secret" | ||
| secretName: "" |
There was a problem hiding this comment.
question: Why not reuse the defaultCredentialsSecret and make this a boolean that indicates whether to use the secret or configMap approach?
Is this a new chart?
No
What this PR does / why we need it:
Migration of the reverse proxy configuration from a ConfigMap to a Secret allows customers to utilize password vaults and CSM-Authorization with the csi reverse proxy.
Which issue(s) is this PR associated with:
Special notes for your reviewer:
secretName, has been added.secretNamevalue to an empty string, otherwise the default value will be used from the csireverseproxy helm chart values file and the driver will attempt to use the reverse proxy secret.X_CSI_POWERMAX_ENDPOINT, has been removed because, now that the reverse proxy is a requirement for installing csi-powermax, it appears to no longer be in use.secretNameis not being used.Checklist:
[charts_dir/mychartname]) if applicable