When a new release is being planned, it is useful to give admins some
notice if the release includes a database migration. Releases without
migrations can be applied with minimal downtime (just the time needed
to unpack the files and restart the daemons).
LAVA is also planning changes to support scaling and high
availability, these changes may involve creating multiple dockers
accessing the same external database. This provides for no downtime
when upgrading to a new LAVA release, each docker could be restarted
independently, jobs can continue to be submitted etc.. However, as
soon as the release includes even one database migration, scheduled
downtime becomes unavoidable and services trying to submit jobs would
get a HTTP502 error. All docker containers would have to be stopped
before the database is migrated and then updated containers started
which use the new code to match the effect of the migrations.
To help admins with future releases, the plan is to "batch up"
migrations into a single release and then give warning on
lava-announce when work starts on that release (not at the point of
announcing the release itself).
Merge requests which include database changes will have the database
changes label applied:
https://git.lavasoftware.org/lava/lava/merge_requests?label_name%5B%5D=Data…
Issues which are expected to require database changes will have the same label:
https://git.lavasoftware.org/lava/lava/issues?label_name%5B%5D=Database+cha…
Issues and merge requests with the label will be put into the same
milestone and the milestone will mention that database changes are
expected:
https://git.lavasoftware.org/groups/lava/-/milestones/2?milestone%5Btitle%5…
When developers are planning changes which include database
migrations, please make sure that this is declared (on this list and
in all issues or merge requests), the relevant label is attached and a
suitable milestone is set.
Avoid merging any MR which has a milestone ahead of the next release.
Milestones are tracked here:
https://git.lavasoftware.org/groups/lava/-/milestones
One suggestion for developers would be to host the change which
includes one or more migrations in a dedicated docker container and
keep your localhost on the master branch.
Comments? Problems?
--
Neil Williams
=============
neil.williams(a)linaro.org
http://www.linux.codehelp.co.uk/
https://git.lavasoftware.org/lava/ci-images/merge_requests/4
I've had problems getting Docker in Docker working on arm64. As the
second main architecture for LAVA, I was looking at how to build arm64
docker images inside GitLab CI - using the same methods as the amd64
builds. A number of issues resulted: The DinD base images are complex
and it's not obvious how to build an arm64 docker image which can run
in privileged mode and build other docker images inside it - certainly
not within our existing GitLab CI. The available arm64 hardware has
lots of cores but is slow at single threaded operations. I manually
built the arm64 docker images to run the unit tests outside of the
GitLab CI, even with -n 18 support to use 18 of the 24 cores, it is
still too slow to use on every change to every merge request. That
then means that automatically building the arm64 docker images is less
of an issue - we can simply run some arm64 tests when a git tag is
pushed. The overall issue will be kept under review but for now, we'll
be fine with manually rebuilding arm64 dockers from time to time and
running arm64 tests only on tags. So the WIP for ci-images has been
abandoned and the WIP on lava will be lower priority.
Other merge requests were discussed too:
https://git.lavasoftware.org/lava/lava/merge_requests/103
The XML_RPC support will gain documentation on how to use the
allow_none setting in XMLRPC clients to help keep the newer XML_RPC
function output consistent.
https://git.lavasoftware.org/lava/lava/merge_requests/14
The skip_timeout support will be tweaked to use a boolean flag in the
timeout block of the test action and the contribution guide updated to
show a distinction that tags should relate to user/device data and
elements relating directly to the code should use the structures
instead.
https://git.lavasoftware.org/lava/lava/merge_requests/12
Excessive messages will be changed to handle the trim inside the
exception handler.
These merge requests will get updates in the next few days.
https://git.lavasoftware.org/lava/lava/merge_requests?scope=all&utf8=%E2%9C…
There are a number of merge requests tagged with the 2018.10 milestone
- these are the ones we are trying to get merged before making a new
upstream release of LAVA.
Finally, a reminder, this list is intended for developers of LAVA to
support discussion of changes before or after a merge request is
opened. Please abide by the Code of Conduct and Contribution Guide.
https://www.lavasoftware.org/code-of-conduct.htmlhttps://master.lavasoftware.org/static/docs/v2/contribution-intro.html
--
Neil Williams
=============
neil.williams(a)linaro.org
http://www.linux.codehelp.co.uk/
