The do-release-upgrade sounds like the way to go then. If you are willing and have the time to upgrade the machines as you recommended, I would love to join you, if possible, so that I have more insights about these processes. Personally, if I would have to upgrade the machines myself, I would just follow the guides from the internet.
Best, Christos On Thu, 27 Mar 2025, 17:33 Uwe Schindler, <u...@thetaphi.de> wrote: > 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 upgr > <https://www.google.com/maps/search/ger+before+requesting+an+upgr?entry=gmail&source=g>ade > from infra. I will > >> also need someone with access to each project to configure the nodes > again > <https://www.google.com/maps/search/to+configure+the+nodes+again?entry=gmail&source=g> > , > >> 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 >
