Bugfix: Reuse existing secrets #137
Conversation
Release v1.1.0
Release v1.1.0
|
Thanks for this contribution @madestreel , we will take it to internal labs to validate it and update you soon. |
There was a problem hiding this comment.
@madestreel The installation fails with preconfigured secret
| @@ -1,17 +1,7 @@ | |||
| apiVersion: v1 | |||
| kind: Secret | |||
| metadata: | |||
| name: memphis-creds | |||
| name: {{ .Values.memphis.creds.secretConfig.name }} | |||
There was a problem hiding this comment.
@madestreel In case the secret already exist in the namespace and its not helm generated the installation fails.
There was a problem hiding this comment.
Could you provide the error? When I tested it worked fine... But it is true that I didn't test with other keys than the defaults one inside the secret
There was a problem hiding this comment.
I've tried to use pre-created secret and this is the output:
Error: INSTALLATION FAILED: rendered manifests contain a resource that already exists. Unable to continue with install: Secret "external-creds" in namespace "memphis" exists and cannot be imported into the current release: invalid ownership metadata; label validation error: missing key "app.kubernetes.io/managed-by": must be set to "Helm"; annotation validation error: missing key "meta.helm.sh/release-name": must be set to "my-memphis"; annotation validation error: missing key "meta.helm.sh/release-namespace": must be set to "memphis"
There was a problem hiding this comment.
I might be mistaken but it seems that the error is more about the fact that the secret cannot be imported to the release more than the chart trying to create a secret that already exist.
There was a problem hiding this comment.
It can't be imported and we don't want so, we want to use an existing pre-configured secret with all the values.
Can you explain a little bit more about the use case you checked?
There was a problem hiding this comment.
Sorry I was not working yesterday so I had not really the chance to test. I will do that today
|
@valeraBr Any news for this? |
|
@madestreel Sorry for the late response, current release is near the corner so this PR will be merged right after it. |
Release v1.2.0
madestreel
force-pushed
the
feature/custom-secrets
branch
from
6552f0c to
b16d28d
Compare
|
@valeraBr Let me know if there is something I need to do here |
|
@madestreel I will, the PR takes time but will be merged soon. |
madestreel
force-pushed
the
feature/custom-secrets
branch
from
b16d28d to
d5594a9
Compare
Release v1.2.2 - Stable
Update Jenkinsfile
Update Jenkinsfile
Latest helm chart
With the current implementation we would have to choice between creating the secret manually or have it auto created but then it will be recreated at each deploy. With this change. If the secret is already present the values of the secret will be reused, otherwise the secret will be created with either the values configured or some random generated values. This way the secret will only be created if it does not exist.
madestreel
force-pushed
the
feature/custom-secrets
branch
from
d5594a9 to
acbb063
Compare
With the current implementation we would have to chose between creating the secret manually or have it auto created but then it will be recreated at each deploy.
With this change. If the secret is already present the values of the secret will be reused, otherwise the secret will be created with either the values configured or some random generated values.
This way the secret will only be created if it does not exist.