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 projectgit 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 commandgit 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.6.x
Navigate in MiaRec UI to Administration -> Maintenance -> Version. If a version of Python is older than 3.6.x, then do the following to update it.
Note, you do not need to update python if the currently installed version is already 3.6.x and a difference is only in the last part of a version like 3.6.3 and 3.6.10.
On the Ansible controller machine, in the inventory file /opt/ansible-miarec/hosts
, change a version of Python to:
python_version = 3.6.10
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.6.10 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
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:
- Terminate the upgrade process (Ctrl+C)
-
Stop gracefully all celery jobs (“gracefull” means that celery deamon will be stopped when all scheduled jobs complete their execution):
3. Stop Apache web server:service celeryd stop service celerybeat stop
4. Re-run Ansible upgrade playbook:service httpd stop
5. The Celery and Apache services should be started automatically as a part of Ansible upgrade process.ansible-playbook -i hosts setup-miarec.yml
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.