-
Notifications
You must be signed in to change notification settings - Fork 223
Migrate from 0.5.4 to 0.6.X with Upgrade script and nameOverride changed #176
Comments
No, changing the namespace + name of the secrets should be enough |
Changing the names of the Secrets seems best to me, however you can specify the names as well here: # These secrets should exist before the Helm is used to deploy this TimescaleDB.
# You can use generate_kustomization.sh to help in creating these secrets, or have
# a look at kustomize/example to see how you could install them.
secretNames:
# This secret should contain environment variables that influence Patroni,
# for example PATRONI_SUPERUSER_PASSWORD or PATRONI_REPLICATION_PASSWORD
# https://patroni.readthedocs.io/en/latest/ENVIRONMENT.html#postgresql
credentials: # defaults to RELEASE-credentials
# This secret should be a Secret of type kubernetes.io/tls, containing
# both a tls.key and a tls.crt
certificate: # defaults to RELEASE-certificate
# This secret should contain environment variables that influence pgBackRest,
# for example, PGBACKREST_REPO1_S3_KEY or PGBACKREST_REPO1_S3_KEY_SECRET
pgbackrest: # defaults to RELEASE-pgbackrest |
So I modified the script to take my nameOverride and namespace into account, is there some way I can validate that everything is all good? |
Hmm, can you share some details about the pod? There shouldn't be any secrets in there,
Could you please share that as plain text instead of a screenshot? |
no probs, I rolled back to 0.5.4, will try the upgrade again and send you the output of describe |
|
I reckon I must have mucked up the script to the point where secrets were copied across incorrectly along with my pgbackrest settings, not sure about my tls stuff but I guess it would be safe to assume they were broken too |
Any updates or insights? |
What is the current state? Some (synchronous) troubleshooting may be useful, you can use https://slack.timescale.com/, where I'm normally available during European weekdays. |
So its still not working, I'm just sitting on 0.5.4 at the moment, I need to identify which secrets I can delete so that it wont mess up my current configuration. I will jump on the slack at some point, but I'm in the Australian Sydney timezone, so seems like it'll be asynchronous debugging for me. I could probably set aside some time after one or two of my workdays to debug with you. |
We ended up needing to swap infrastructure providers anyway, so we provisioned the 0.6 version of the helm chart on our new cluster - everything running smoothly. Although it doesn't fix the issue, I am no longer affected, I appreciate the help in any case. |
Hi,
I'm really looking forward to upgrading to the 0.6 version of the timescaledb-single helm chart to get TimescaleDB 1.7.
I just finished reading through the upgrade guide and grabbed the shell script to migrate the secrets across. I have run into a problem where I have set the
nameOverride
field in the values.yaml to "mydbname-timescale" from "timescaledb".Along with that, I have specified a specific namespace to place the helm chart into. The namespace is called "databases".
The current script provided doesn't seem to take these changes into account. What sort of changes need to be made to the script to successfully migrate across?
Will it involve more than just changing the namespace + name of the secrets?
Cheers,
Nick
The text was updated successfully, but these errors were encountered: