It has become impractical to maintain support for the latest production
releases on Ubuntu Trusty 14.04LTS due to behaviour required by the
server side changes needed by the dispatcher refactoring. These are
important changes and are impractical to backport to the version of
python-django available in Trusty.
I have tried working around the issues but it involves pulling more
dependencies from Jessie or Vivid and in my tests, the existing
installation became confused and failed to install due to problems with
the database migrations. The LAVA software team do not have the
resources to maintain backports of the complete dependency chain in
Ubuntu, it is a much more manageable set in Debian Jessie (where the
same migration went without issues on multiple machines).
The changes in 2015.11 are almost exclusively related to the dispatcher
refactoring and therefore there is expected to be limited impact on
current installations on Trusty.
For the next release, we will investigate code changes which omit the
new support for Trusty builds but this will have the effect of
preventing those installs from working with the pipeline and the new
YAML job submissions. The documentation for Trusty will also be
updated, if necessary as a hotfix to 2015.9 just for Trusty.
If the code changes do not work cleanly, then the current 2015.9 (and
the documentation hotfix to follow) would become the last LAVA releases
for Ubuntu Trusty 14.04LTS.
Users of Ubuntu Trusty 14.04LTS are reminded that a new LTS is due for
release in April 2016 but that the LAVA software team are not using
Trusty any longer. Any issues with the migration from Trusty to the
new LTS are outside of our control.
Migrating an instance from Ubuntu to Debian would involve dumping and
re-importing the database - bear in mind that Trusty has postgres9.3 and
Jessie has 9.4, so care will be needed to migrate the postgresql
cluster correctly - there is documentation for that migration in the
lava-server docs. It is not recommended to attempt to migrate the OS
itself from Ubuntu to Debian (or vice-versa), a reinstall is a better
option, so make a backup and ensure that the backup works.
--
Neil Williams
=============
neil.williams(a)linaro.org
http://www.linux.codehelp.co.uk/
After discussions at the LAVA Users Forum at Connect SFO15 [0], the LAVA
team have arranged for some changes in the mailing lists to make it easier
to announce and manage the upcoming changes from the ongoing refactoring.
https://lists.linaro.org/mailman/listinfo/lava-users - a discussion list
amongst users for users, with some admins listening in and helping out.
Users in this sense includes test writers and administrators of LAVA
instances outside Linaro. It is particularly aimed at those running LAVA in
places where Linaro is not necessarily aware of the install. I'm not asking
for LAVA instances to declare themselves, it is free software after all, it
is an offer of assistance and a request that users take advantage of the
support available to manage the implications of the refactoring for their
own use cases. Please feel free to initiate threads and discuss issues and
problems on the lava-users list.
As a reminder, for those who use LAVA but have not recently been to a
Connect, the dispatcher is being refactored and this had led to
advancements and modifications in the lava-server as well as a completely
re-written job submission format. LAVA is retaining compatibility *only*
with the Lava Test Shell Definitions (the YAML files people are currently
using) and there can be no automated way of converting existing JSON job
submissions to the new job submission format (which uses YAML to allow for
comments, amongst other improvements).
The timetable for these changes is expected to cover most of 2016. After
https://validation.linaro.org/ has migrated to the new code, the current
dispatcher code will start to be removed from the upstream in 2017.
One result of these changes is that as the Linaro production instance
migrates away from the current dispatcher codebase, there is a likelihood
of some breakage in some parts of the current dispatcher. (This is one of
the primary reasons why the dispatcher is being refactored.)
The refactoring introduces a lot of benefits, including much more robust
communication between the workers and the master, removal of configuration
on the workers so that admins only change things in one place, a lot of new
methods within the dispatcher to support new types of test and a much
cleaner, more modular, codebase for future development.
Also, the Linaro Validation Mailman List <linaro-validation(a)lists.linaro.org>
is to be renamed (keeping linaro-validation as an alias) to lava-devel for
consistency with lava-users and lava-announce. There will be a separate
email to the linaro-validation list about these changes shortly.
These new mailing lists will be included in the documentation included in
next release of the LAVA software (2015.10). Documentation of the new code
is already in the master branch of lava-server and installed via the
lava-server-doc package and the initial code for the refactoring is being
developed in parallel with the current code. This list will be used to
announce when the refactoring codebase is ready for admins to begin
migrating tests and test writers to the new code and methods - currently,
the new dispatcher is developer only. At SFO15, there was also an update on
the state of the refactoring. [1]
lava-announce will continue to be a low volume list. Reply-To has been set
to the linaro-validation mailing list (transparently migrating to
lava-devel once the linaro-validation alias is in place).
The LAVA developers would ask that everyone running LAVA would subscribe to
at least the lava-announce mailing list, to help with the migration to the
new support.
Videos will be available for most meetings at SFO15 in due course. The
slides are already available.
[0] https://sfo15.pathable.com/meetings/302656
[1] https://sfo15.pathable.com/meetings/303074
--
Neil Williams
=============
Tech Lead, LAVA software team.
neil.williams(a)linaro.org
http://www.linux.codehelp.co.uk/
