Hi,
I tried the do-release-upgrade on the older 18.04 machine. Unfortunately
it does not work, as there are too many PPA repositories in the config
(nodejs,....) and those lead to package conflicts so do-release-upgrade
bails out.
I could uninstall all those PPAs with "ppa-purge", but I don't know how
to get puppet to reinstallthem after upgrade.
So it looks like we need to do the "rebuild node" with fresh OS provided
by ASF. That's the problem of nailed down instances with horrible puppet
(sorry, but puppet is the worst tool that I try to avoid at all of my
customers, it always causes issues administering machines for Solr
installations!).
I can do the jenkins home directory backup tomorrow and then we can ask
them to reinstall newer OS. We just need to make sure to tell them that
they should use a puppet configuration that contains all packages we
need for Jenkins Slaves.
Uwe
Am 28.03.2025 um 23:02 schrieb Christos Malliaridis:
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 <mailto:email%3a...@thetaphi.de>
--
Uwe Schindler
Achterdiek 19, D-28357 Bremen
https://www.thetaphi.de
eMail:u...@thetaphi.de <mailto:email%3a...@thetaphi.de>
--
Uwe Schindler
Achterdiek 19, D-28357 Bremen
https://www.thetaphi.de
eMail:u...@thetaphi.de
