gateway - run the georchestra gateway with a Java runtime 21 (fixes geor/geor#4285)

[pmauduit]

Hopefully a JRE 21 will be available in the next debian release, but waiting for it, we can set up a temurin-21-jre from adoptium, see georchestra/georchestra#4285

Tests:

• rspec ok after having installed exim4-base and relaunched the DF
• runtime tests ok: weird redirection to CAS, but able to log in by hitting /login directly (through the georchestra gateway).

[landryb]

there's another reference to the default java version in the df:
roles/georchestra/templates/datafeeder/datafeeder.service.j2:ExecStart=/usr/bin/java

installing temurin 21 will change the default java version .. no ? does the df backend work with java 11 ? 17 ? 21 ? any of them ?

[pmauduit]

installing temurin 21 will change the default java version .. no ?

Hmm, right :-/

vagrant@bookworm:~$ java -version
openjdk version "21.0.4" 2024-07-16 LTS
OpenJDK Runtime Environment Temurin-21.0.4+7 (build 21.0.4+7-LTS)
OpenJDK 64-Bit Server VM Temurin-21.0.4+7 (build 21.0.4+7-LTS, mixed mode, sharing)

I think we should avoid the update-alternatives step here, and I'd like to only affect the gateway, not the other apps.

[pmauduit]

does the df backend work with java 11 ? 17 ? 21 ?

it works with both java 17 & 21 in my vagrant.

[pmauduit]

I checked if there was a way to avoid temurin-21 to become the default jre, but the postinst script does not allow it, so maybe playing with the alternatives ansible module after having setting it up ? e.g.:
https://docs.ansible.com/ansible/latest/collections/community/general/alternatives_module.html

For the record, here is the postinst provided by the temurin package:

#!/bin/sh
set -eu

priority="2111"
jdk_base_dir="/usr/lib/jvm/temurin-21-jdk-amd64"
tools="jar jarsigner java javac javadoc javap jcmd jconsole jdb jdeprscan jdeps jfr jhsdb jimage jinfo jlink jmap jmod jpackage jps jrunscript jshell jstack jstat jstatd jwebserver keytool rmiregistry serialver jexec jspawnhelper"

case "$1" in
configure)
	for tool in $tools; do
		for tool_path in "$jdk_base_dir/bin/$tool" "$jdk_base_dir/lib/$tool"; do
			if [ ! -e "$tool_path" ]; then
				continue
			fi

			slave=""
			tool_man_path="$jdk_base_dir/man/man1/$tool.1"
			if [ -e "$tool_man_path" ]; then
				slave="--slave /usr/share/man/man1/$tool.1 $tool.1 $tool_man_path"
			fi

			update-alternatives \
				--install \
				"/usr/bin/$tool" \
				"$tool" \
				"$tool_path" \
				"$priority" \
				$slave
		done
	done
	;;

abort-upgrade | abort-remove | abort-deconfigure)
	# Nothing to do
	;;
*)
	echo "postinst called with unknown argument \`$1'" >&2
	exit 1
	;;
esac

exit 0

[landryb]

i'm totally fine with using the alternatives module, i have that somewhere:

- name: Default to temurin jdk
  community.general.alternatives:
    name: java
    path: /usr/lib/jvm/temurin-11-jdk-amd64/bin/java

the only question left is 'should this be done for all binaries provided by the jre/jdk'...

[pmauduit]

the only question left is 'should this be done for all binaries provided by the jre/jdk'...

I guess so, my fear was to have more tools from one side or another (between java21 vs java17).

[landryb]

there doesnt seem to be a dpkg/apt option to avoid running postinst scripts...

[pmauduit]

there doesnt seem to be a dpkg/apt option to avoid running postinst scripts...

I have seen a hackish solution on stackoverflow, but I did not want to go in that direction (exit 0 in a /etc/apt/something.d directory where you can put hooks)

[pierrejego]

I just tried with

# We don't want java 21 to be the default version
- name: Get Java major version currently active
  shell: java -version 2>&1 | grep -oP 'version "\K[0-9]+' 
  register: java_major_version

- name: Extract wanted Java major version from configuration
  set_fact:
    wanted_java_version: "{{ java_version | regex_replace('^java-([0-9]+)-.*', '\\1') }}"

- name: Update Java alternatives if needed
  alternatives:
    name: java
    path: "/usr/lib/jvm/{{ java_version }}/bin/java" 
  when: java_major_version.stdout | int > wanted_java_version | int 

Seems good for me,
I can push a commit on our branch if you want

[pmauduit]

you will still encounter the non-convergence issue, see https://willthames.github.io/2016/09/21/using-command-and-shell-in-ansible.html

When you run command or shell, they always set changed to True. This is because Ansible has no mechanism for understanding whether your command changed anything or not. Some commands are genuinely read only (e.g. git status) and others have side effects.

Generally, one expects with Ansible that when a playbook is run twice, no changes should happen on the second run. There are (at least) four ways to achieve this (ansible-lint only checks these four, so if there’s another mechanism, let me know).

I'd suggest to add a changed_when to the shell command

[landryb]

wouldnt it be simpler to just run the alternatives module regardless of the existing default version ? this way, if it's not 17, then the task is run, otherwise, it's .. skipped ? or i missed something...

[pierrejego]

wouldnt it be simpler to just run the alternatives module regardless of the existing default version ? this way, if it's not 17, then the task is run, otherwise, it's .. skipped ? or i missed something...

@pmauduit didn't want to launch alternative if not needed. And alternative ansible module doesnot seem to check before changing. Code proposed will do the check, and change_when will avoid to have a change displayed if JVM already good.

( this is well explain here; https://www.middlewareinventory.com/blog/ansible-changed_when-and-failed_when-examples/ )

[pmauduit]

@pmauduit didn't want to launch alternative if not needed.

That is what I wanted to do in my PR actually, but since the playbook does not converge anyway, and @landryb suggests it, I guess we could make an exception for this step, I don't really mind ;-)