Use virtual Java packages on Red Hat and set java_bin #2
Conversation
| # Location of your Java binary (version 8) | ||
| JAVA_BIN="/usr/bin/java" | ||
| # Location of your Java binary | ||
| #JAVA_BIN="" |
There was a problem hiding this comment.
I believe the CLI also uses this. There's places like https://github.com/OpenVoxProject/openvox-server/blob/da7e9916bcb456e0793d69a1e69e0edeb5bdfc05/resources/ext/cli_defaults/cli-defaults.sh.erb#L7 others in the puppetserver repo that use this.
When testing this, I think running puppetserver --help or puppetserver ruby should trigger any error if it isn't set.
|
@ekohl Ready for rebase |
| @@ -14,6 +14,7 @@ | |||
| options.old_sles = 0 | |||
| options.sles = 0 | |||
| options.java = 'java-1.8.0-openjdk-headless' | |||
| options.java_bin = '/usr/bin/java' | |||
There was a problem hiding this comment.
I was never a fan of this path. I think there is a java11/java17 symlink as well that we could use? We don't really know to what usr/bin/java points and I had multiple issues at customers where this was pointing to a too new or too old jre.
There was a problem hiding this comment.
Edit: Ah you are setting it properly below, nevermind.
| case options.platform_version | ||
| when 8 | ||
| # rpm on Redhat 7 may not support OR dependencies | ||
| if options.os_version == 7 |
There was a problem hiding this comment.
Do we still need EL7 specific code?
There was a problem hiding this comment.
We're still building el7 for the moment. But I'd be in favor of dropping it if everyone else is.
There was a problem hiding this comment.
@ekohl I think you rely on puppet 7 for satellite, but do you also need it for EL7?
There was a problem hiding this comment.
EL7 isn't entirely dead downstream but that's more on the agent side. I think we can stop building server because at least in Satellite we don't support that.
| # rpm on Redhat 7 may not support OR dependencies | ||
| if options.os_version == 7 | ||
| options.java = 'jre-11-headless' | ||
| options.java_bin = '/usr/lib/jvm/jre-11/bin/java' |
There was a problem hiding this comment.
Is this (and the 17) path a stable path for all distributions of Java?
There was a problem hiding this comment.
I'm not sure it is. On debian 12 with openjdk 17, it's /usr/lib/jvm/java-17-openjdk-arm64/bin/java, for example.
There was a problem hiding this comment.
Oh, but that's jdk, not jre. Lemme try that.
There was a problem hiding this comment.
Nope, I'm wrong, that is with openjdk-17-jre-headless installed. So yeah, not sure this path is one we can rely on.
The if condition on line 190 already guarantees that os_version is at least 7 so the else can never be reached. This further simplifies the condition.
Making it a config option allows for differentation. The comment for version 8 was outdated, since puppetserver 8 refuses to start up with Java 8.
The EnvironmentFile paths are config locations so if a user ever modified them, they're not replaced. By defining this in the service file, the packaging will update the location. The result is that even if a java location changes that a simple yum/apt upgrade will respect the new value in most situations.
This is a noop refactor, but makes the later diffs easier to read.
This uses the virtual packages jre-VERSION-headless instead of
explicitly openjdk. This allows other JREs to provide the same.
It also uses an explicit path to the JRE specific java bin. At least on
EL9 this allows the following upgrade path to work:
dnf install https://yum.puppet.com/puppet7-release-el-9.noarch.rpm
dnf install puppetserver
dnf install https://yum.puppet.com/puppet8-release-el-9.noarch.rpm
dnf upgrade puppetserver
Prior to this patch it would break, because it used /usr/bin/java which
will point to Java 8. By using /usr/lib/jvm/jre-17/bin/java we know for
sure it is Java 17.
This is puppetlabs/ezbake#627 opened against OpenVoxProject. I have only done an initial rebase without resolving all the issues.
I'll add inline notes with where we need to have further discussion.