Ansible-based update on Linux

1. Update MiaRec playbooks

From time to time, we update playbooks for MiaRec installation/update. It doesn't occur with every software release, but sometimes we introduce new features to our product, that require update of installation scripts as well.

The MiaRec Ansible playbooks are hosted on public GitHub repository. To see if there were any changes to the playbooks, you can check the commit history.

Note, it will not harm to execute below commands even if there were no any changes to playbooks.

To load the latest version of playbooks, execute the following command on the Ansible controller machine:

cd /opt/ansible-miarec
git pull
git submodule update -i --recursive

Explanation:

• git pull command will load the latest version of the top project
• git submodule update ... command will load the latest version of the sub-projects (submodules).

If you see the error "Your local changes to the following files would be overwritten by merge", then some of local files have been edited manually on your server and the same files have been updated in the MiaRec github repository. You can run git diff command to see exactly what changes were made to the local files. To revert changes, you can execute command git checkout -- FILE_NAME. Where, FILE_NAME is the name of the file to revert changes.

Then try again to pull the latest version from the MiaRec repository.

2. Update to Python 3.11.x

Navigate in MiaRec UI to Administration -> Maintenance -> Version. If a version of Python is older than 3.11.x, then do the following to update it.

Note, you do not need to update python if the currently installed version is already 3.11.x and a difference is only in the last part of a version like 3.11.1 and 3.11.7.

On the Ansible controller machine, in the inventory file /opt/ansible-miarec/hosts, change a version of Python to:

python_version      = 3.11.7

Then run the prepare-hosts playbook to install python:

cd /opt/ansible-miarec
ansible-playbook -i hosts prepare-hosts.yml -t python

This playbook will install Python 3.11.7 on the server.

Confirm the satisfactory completion with zero items unreachable or failed:

PLAY RECAP ********************************************************************
...
miarec                :  ok=38   changed=8   unreachable=0    failed=0

3. Update the MiaRec version info in the inventory file

On the Ansible controller machine, edit the version info in the inventory file /opt/ansible-miarec/hosts.

Example of this file:

[all:vars]
; -------------------------------
; Version of installed packages
; -------------------------------
miarecweb_version   = x.x.x.x
miarec_version      = y.y.y.y
miarec_screen_version = z.z.z.z 
miarec_livemon_version = w.w.w.w 

Contact your MiaRec representative to receive the latest version info.

4. Run playbook

To update MiaRec, run the following command:

cd /opt/ansible-miarec

ansible-playbook -i hosts setup-miarec.yml

When using password authentication, then add --ask-pass to the above command, like:

ansible-playbook -i hosts setup-miarec.yml --ask-pass

Confirm the satisfactory completion with zero items unreachable or failed:

PLAY RECAP ********************************************************************
...
miarec                :  ok=38   changed=25   unreachable=0    failed=0

Resolve issue "Upgrade is stuck at the task Upgrade database layout"

If the upgrade process is stuck at the task "Upgrade database layout" for too long (more than 15 minutes), then do the following:

1. Terminate the upgrade process (Ctrl+C)

2. Stop gracefully all celery jobs (“gracefull” means that celery deamon will be stopped when all scheduled jobs complete their execution):

   service celeryd stop
   service celerybeat stop
   

   3. Stop Apache web server:

   service httpd stop
   

   4. Re-run Ansible upgrade playbook:

   ansible-playbook -i hosts setup-miarec.yml
   

   5. The Celery and Apache services should be started automatically as a part of Ansible upgrade process.

   service celeryd start
   service celerybeat start
   service httpd start
   

Why the upgrade process may stuck at the task "Upgrade database layout"?

We continuously add new features to our product. Some features require changes to database layout, like add column, table, etc. Some changes to database layout may require an exclusive lock on affected tables. The upgrade process may stuck waiting for a lock to be acquired. If other services are actively accessing database, it may take too long to acquire the lock.

Note, above instructions instruct how to stop web server and celery services only. The recording service doesn't have to be stopped. It continues to record calls even when web server and/or celery services are down. The recorder service also accesses the database, but it does not prevent acquiring a lock on table because recorder doesn't use transactions.