Upgrading your LA portal

Content-Type: text/enriched Text-Width: 80

Strategies to upgrade a LA portal

In general there are two main strategies to migrate your LA services and servers:

a) To install new servers and services from scratch using new versions of everything (like the OS), redeploy with #A8CE93</x-color>ansible`` & <x-color><param>#A8CE93</param>ala-install#A8CE93</x-color> and restore dbs and `/data<x-color><param>#A8CE93</param> from backups or rsync or similar. In general the philosophy of #A8CE93[#7FC1CAdevops#A8CE93](#D18EC2https://en.wikipedia.org/wiki/Devops#A8CE93) (and #A8CE93</x-color>ansible<x-color><param>#A8CE93</param> and #A8CE93</x-color>ala-install<x-color><param>#A8CE93</param>) is to not touch servers manually, so if you have a good LA inventory (these generated by the la-toolkit, for instance) and you didn't install or configured nothing manually, it's quite easy to reproduce and restore servers and services or upgrade them. You'll need extra servers, and it's quite safe because you don't switch to production the new servers until you are sure that are working. b) To upgrade using the same servers. This is more risky, but sometimes easy, when you are doing small version upgrades. You can also do OS upgrades that way, but the same, it's more risky as you are upgrading production servers.

In general with option a) you play with #A8CE93</x-color>/etc/hosts<x-color><param>#A8CE93</param>, or DNS and/or proxies until you are sure that the updated service is working and you change the DNS/proxies to put that new servers in production.

In which order we need to upgrade a LA Portal?

We don't have an unique order to upgrade modules, but there are some LA modules that are more easy to upgrade than others.

So you can try to upgrade LA services that do not have a db backend theyself, like #A8CE93</x-color>regions<x-color><param>#A8CE93</param> or #A8CE93</x-color>bioacache-hub<x-color><param>#A8CE93</param>, #A8CE93</x-color>bie-hub<x-color><param>#A8CE93</param>, #A8CE93</x-color>biocache-service<x-color><param>#A8CE93</param>... These are more safe to migrate or test and to downgrade if you detect some issue.

Also sometimes you have to migrate some services to maintain compatibilities and #A8CE93[#7FC1CAdependencies#A8CE93](#D18EC2https://github.com/AtlasOfLivingAustralia/documentation/wiki/Dependencies#A8CE93).

Keeping your /data/ configs well configured

If you managed your #A8CE93</x-color>/data/*/config<x-color><param>#A8CE93</param> manually for some reason instead of using #A8CE93</x-color>ansible<x-color><param>#A8CE93</param> and you want to use #A8CE93</x-color>ala-install<x-color><param>#A8CE93</param> instead, you have to create a correct #A8CE93</x-color>ansible<x-color><param>#A8CE93</param> inventory with all these manual #A8CE93</x-color>/data/<x-color><param>#A8CE93</param> configurations translated to the ansible variables inventories. For this is good to keep track of you configurations. We tried to describe this (and other related recommendations) #A8CE93[#7FC1CAhere#A8CE93](#D18EC2https://github.com/AtlasOfLivingAustralia/documentation/wiki/Version-control-of-your-configurations#A8CE93).

Cassandra

Schemas migration

From #A8CE93[#7FC1CAtime#A8CE93](#D18EC2https://github.com/AtlasOfLivingAustralia/ala-install/commit/127f0d9388f286f759eac6094f4bcc2b2f0d5d06#diff-bcc68e4707423d31c813b2c91e505563#A8CE93) to #A8CE93[#7FC1CAtime#A8CE93](#D18EC2https://github.com/AtlasOfLivingAustralia/ala-install/commit/7794e32df2e75027e116c5efb0e1ad1eeafb6c6f#A8CE93) our cassandra schema changes. We can use #A8CE93</x-color>ALTER TABLE<x-color><param>#A8CE93</param> statements to update it, however the #A8CE93</x-color>biocache-store<x-color><param>#A8CE93</param> detects missing fields and adds them automatically.

Migration notes

#DF8C8C- https://github.com/AtlasOfLivingAustralia/documentation/wiki/Image-Service-migration

And remember

Backup, backup, backup