Updating issues

🚧 Installation
#1

I had issdues upgrading from 2020.12 to 2021.3, I got stuck in the “auth” loop and nothing I tried seemed to sort it.

As a result I am still using the same version of Corteza (2020.12)

My question is… If I take a snapshot of my server before I try to upgrade again… If the upgrade poses any issues, will restoring the snapshot also restore Corteza to the point before the upgrade?
If not, can I roll it back to 2020.12?

I dont want to try upgrading if there will be any potential issues.

#2

When you do an upgrade there are usually (in your case there will be) some database modifications that would make it incompatible with your current version 2020.12. With that said, taking a snapshot of just your server probably won’t do any good for you in case something goes wrong.
The server is fairly stateless as the data is stored in a separate DB container.

What we usually do/suggest is the following flow:

  1. Set up a staging/testing instance on a completely different server/on your local machine and see if it works out as you expected.
    If not, determine the steps needed to resolve the issues.
  2. Before updating your production instance, make a database backup.
    Do make sure that your backup is valid (you can inspect the contents of the .sql file) – sometimes misconfigured permissions may cause some issues.
  3. Update your instance

If there is an unexpected issue you’ll have your DB backup ready to restore.

Sometimes, because I find it “less stressful”, I do the following flow:

  1. Set up a local instance based on the production instance I am updating (I make sure my local version matches their current version)
  2. I update my local version to the latest version
  3. I migrate my local testing database to the production server I am updating (making sure to match the versions).
#3

Thank you for your reply.
I have tried that before… I struggled with the upgrade, as mentioned above, as I got stuck in the Auth loop.
I used the same .env and YAML files in a local test and it ran fine, without any issues.
I managed to use Corteza as expected.
The issue only seemed to occur in the live production enviroment.

#4

Not too long ago I was updating a 2020.12 instance to the (at the time) latest 2021.9.1 version and I can’t recall I had any major issues (I did update to the intermediate 2021.3 version; so 2020.12 → 2021.3.10 → 2021.9.1 if I recall the patch versions correctly – the patch versions shouldn’t really matter; use the latest stuff).

If you are having issues only on a server, in your case, I would check your configuration to make sure everything is as it should be, especially the DOMAIN .env variable.

If still not resolved, I would then check directly in the database, in the auth_clients table if the default auth client is configured correctly (mainly the redirect_url column.

Try the above on a staging server, as remote deployments are where you seem to have issues on.

This is what I can think of from the top of my head, but it could probably be a number of other things. If the above doesn’t resolve it might be faster and easier to get a DevOps guy to help you out.

#5

@tjerman I tried that before, the test environment worked fine, the live environment got stuck in the loop

would it be possible to create a second instance of Corteza in a separate folder (Corteza2) and using different pot numbers where I can test the the updated versions as a live deployment.

and either
Use the existing database credentials so that it pulls the stored info straight from the database that the current install is using

Or
take a dump from the main live install and “restore” the dump in the new corteza2 folder
?

#6

Just make sure that you configure your systems correctly.

That would most likely result in the same issues as before.
The initial issue was most likely related to some database values not being set correctly (probably auth clients).

Same as above.