Existing remote workers with both V1 and V2 device support will need to
migrate to supporting V2 only. Once all devices on the worker can
support V2, the admin can disable V1 test jobs on that worker.
Caution
Due to the way that V1 remote workers are configured, it
is possible for removal of V1 support to erase data on the
master if these steps are not followed in order. It is particularly
important that the V1 SSHFS mountpoint is handled correctly and that
any operations on the database remain local to the remote worker
by using psql instead of any lava-server commands.
All device types on the dispatcher must have V2 health checks
configured.
Remove V1 configuration files from the dispatcher. Depending on
local admin, this may involve tools like salt or ansible
removing files from /etc/lava-dispatcher/devices/ and
/etc/lava-dispatcher/device-types/
Ensure lava-slave is pinging the master correctly:
tail -f /var/log/lava-dispatcher/lava-slave.log
Check for existing database records using psql
Note
Do not use lava-server manage shell for this step
because the developer shell has access to the master database,
use psql.
Check the LAVA_DB_NAME value from
/etc/lava-server/instance.conf. If there is no database with
that name visible to psql, there is nothing else to do for this
stage.
$ sudo su postgres
$ psql lavaserver
psql: FATAL: database "lavaserver" does not exist
If a database does exist with LAVA_DB_NAME, it should be empty.
Check using a sample SQL command:
=# SELECT count(id) from lava_scheduler_app_testjob;
If records exist, it is up to you to investigate these records and
decide if something has gone wrong with your LAVA configuration or
if these are old records from a time when this machine was not a
worker. Database records on a worker are not visible to the
master or web UI.
Stop the V1 scheduler:
sudo service lava-server stop
umount the V1 SSHFS which provices read-write access to the test
job log files on the master.
- Check the output of
mount and
/etc/lava-server/instance.conf forthe value of LAVA_PREFIX. The SSHFS mount is
${LAVA_PREFIX}/default/media. The directory should be empty once the
SSHFS mount is removed:
$ sudo mountpoint /var/lib/lava-server/default/media
/var/lib/lava-server/default/media is a mountpoint
$ sudo umount /var/lib/lava-server/default/media
$ sudo ls -a /var/lib/lava-server/default/media
. ..
Check if lavapdu is required for the remaining devices. If not,
you may choose to stop lavapdu-runner and lavapdu-listen,
then remove lavapdu:
sudo service lavapdu-listen stop
sudo service lavapdu-runner stop
sudo apt-get --purge remove lavapdu-client lavapdu-daemon
Unless any other tasks on this worker, unrelated to LAVA, use the
postgres database, you can now choose to drop the postgres cluster
on this worker, deleting all postgresql databases on the worker.
(Removing or purging the postgres package does not drop the
database, it continues to take up space on the filesystem).
sudo su postgres
pg_lsclusters
The output of pg_lsclusters is dependent on the version of
postgres. Check for the Ver and Cluster columns, these
will be needed to identify the cluster to drop, e.g. 9.4 main.
To drop the cluster, specify the Ver and Cluster to the
pg_dropcluster postgres command, for example:
pg_dropcluster 9.4 main --stop
exit
If lava-coordinator is installed, check the local config is not
localhost in /etc/lava-coordinator/lava-coordinator.conf and
then stop lava-coordinator:
sudo service lava-coordinator stop
Caution
lava-coordinator will typically be uninstalled in a
later step. Ensure that the working coordinator configuration is
retained by copying
/etc/lava-coordinator/lava-coordinator.conf to a safe
location. It will need to be restored later. The coordinator
process itself is not needed on the worker for either V1 or V2
was installed as a requirement of lava-server, only the
configuration is actually required.
Remove lava-server:
sudo apt-get --purge remove lava-server
Remove the remaining dependencies required for lava-server:
sudo apt-get --purge autoremove
This list may include lava-coordinator, lava-server-doc,
libapache2-mod-uwsgi, libapache2-mod-wsgi, postgresql,
python-django-auth-ldap, python-django-restricted-resource,
python-django-tables2, python-ldap, python-markdown,
uwsgi-core but may also remove others. Check the list carefully.
Check lava-slave is still pinging the master correctly.
Check for any remaining files in /etc/lava-server/ and remove.
Create the /etc/lava-coordinator directory and restore
/etc/lava-coordinator/lava-coordinator.conf to restore MultiNode
operation on this worker.
Check for any remaining lava-server processes - only lava-slave
should be running.
Check if apache can be cleanly restarted. You may need to run sudo
a2dismod uwsgi and sudo a2dissite lava-server:
sudo service apache2 restart
Copy the default apache2 lava-dispatcher configuration into
/etc/apache2/sites-available/ and enable:
cp /usr/share/lava-dispatcher/apache2/lava-dispatcher.conf /etc/apache2/sites-available/
$ sudo a2ensite lava-dispatcher
$ sudo service apache2 restart
$ sudo apache2ctl -M
$ wget http://localhost/tmp/
$ rm index.html
Undo fuse configuration
V1 setup required editing /etc/fuse.conf on the worker and
enabling the user_allow_other option. This can now be disabled.
Run healthchecks on all your devices.
