Mortom123 commented on code in PR #448:
URL: https://github.com/apache/pulsar-helm-chart/pull/448#discussion_r1469702242
##########
charts/pulsar/values.yaml:
##########
@@ -1326,11 +1327,13 @@ pulsar_manager:
hostname: ""
path: "/"
- ## If set use existing secret with specified name to set pulsar admin
credentials.
+ ## If set use an existing secret with specified name to set pulsar admin
credentials
+ ## Leave empty to generate either a new secret with random passwords or
reuse one from a previous installation
+ ## You can find out the actual password by running the following command:
+ ## kubectl get secret -l app=pulsar-manager -o=jsonpath="{.items[0].data}" |
base64 --decode
+ ## And decode any key by using:
+ ## kubectl get secret -l app=pulsar-manager
-o=jsonpath="{.items[0].data.KEY}" | base64 --decode
existingSecretName:
Review Comment:
After thinking about it - if I were the end user installing the pulsar helm
chart, I would probably prefer tuning some values instead of deploying a
secret. So putting it into there might also be a good choice.
However, if the enduser uses something that autogenerates secrets from an
external application, providing a Secret name might also be needed.
So we have these decision to make:
1. provide the user with UI_USERNAME / UI_PASSWORD options in the
values.yaml file to set their given credentials, yes / no?
2. provide the user with the possibility to overwrite the default secret
name with `existingSecretName`, meaning he needs to inject the secret. yes / no?
My choice would probably be:
1. yes
2. no
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
