Small update: both machines already use netplan and not old interfaces
file, so do-release-upgrade is a no-brainer.
Uwe
Am 27.03.2025 um 16:23 schrieb Uwe Schindler:
Hi,
I have root access on both machines. Indeed one of them (lucene-solr1)
is Ubuntu 18.04 LTS and the other one (lucene-solr - no digit) is
Unbuntu 20.04 LTS. In fact, both are outdated, whereas the first one
is out of support as far as I remember.
There are two ways:
* do-release-upgrade => this works well on Ubuntu LTS nodes, never
had a problem with that. In fact the one on Ubuntu 20.04 was
updated like this (as far as I remember). The big downside: It
takes lots of time, as we need for the older machine 3 rounds and
reboots (and possibly having netplan issues) and 2 rounds for the
newer one. I can do this, if needed. The pros are that we can for
sure use our instances after that without Infra changing Jenkins.
Infra still needs to be pinged afterwards to update puppet version
(this was how it was done last time).
* reinstall everthing => this has the problem that there were
changes on the nodes which might be done in the jenkins home
directory. If we do this (and that's what you are suggesting),
please make a "tar cf" of the jenkins user home directory to make
sure all config files in ".gradle" and the home dir are copied. Of
course before doing this, do a "rm-rf" in the
"jenkins-slave/workspace" folder. The config files in the root
directory are there to instruct gradle how many cpus should be
used for the build to max out the hardware. The gradle default
installed by our gradle build do not max out the CPUs to allow
development in parallel. So it is important to copy
lucene.build.properties (for Lucene/Solr 8x. legacy builds) and
.gradle/gradle.properties to the new node. Also make sure to do a
list of all dpkg packages, so we don't forget something we might
need. With my recent experience, the defaults should be enough (we
no longer build with crazy tools).
Personally I am not a big fan of "reinstall OS because something does
not work". This has the side effect of a lot of time of non-working
builds because some stupid detail is missing or INFRA needs to install
some of their custom Java packages over and over. With the usual
round-trip-times of Infra this takes days.
Some story on my own Jenkins server: I had to do a reinstallation with
the macOS Jenkins Slave on Policeman Jenkins but it costed me half of
a day to get the builds running again (OK, macOS is harder, but
reinstalling missing stuff, setting up SSH keys,... is a stupid task).
Transplanting the Windows node (that was easy) and also the whole
server from old hardware to a new hardware was much faster (1.5 hrs
where most of the time was waiting for the rsync in recovery console
and updating EFI build, actually there ways no setup necessary at all
- it booted straight out of box and Jenkins autostarted and went back
to work).
Important info: The setup of the nodes inside Jenkins can only be done
by Infra, we have no access. Generally it is better to not change to
much on the nodes and just upgrade them (first point above).
Uwe
Am 26.03.2025 um 18:04 schrieb Christos Malliaridis:
Hello everyone,
In consultation with David Smiley, I am planning to request an OS upgrade
for our build nodes *lucene-solr-1* and *lucene-solr-2* on Monday, March
31, as they are running older operating systems and causing OS-related
build errors in the Solr project.
Since the nodes will be replaced with new instances, they will need to be
reconfigured for both projects. Please speak up if this may be an issue or
if I should wait longer before requesting an upgrade from infra. I will
also need someone with access to each project to configure the nodes again,
as I do not currently have sufficient access.
Best,
Christos
--
Uwe Schindler
Achterdiek 19, D-28357 Bremen
https://www.thetaphi.de
eMail:u...@thetaphi.de
--
Uwe Schindler
Achterdiek 19, D-28357 Bremen
https://www.thetaphi.de
eMail:u...@thetaphi.de
