Jira (PDB-5630) RHEL Platform 7 to Platform 8 upgrade failure

[Austin Blatt (Jira)]

Austin Blatt created an issue

PuppetDB / PDB-5630 RHEL Platform 7 to Platform 8 upgrade failure Issue Type: Bug Assignee: Unassigned Created: 2023/04/17 1:59 PM Priority: Normal Reporter: Austin Blatt Problem: On RedHat-based OSes, PuppetDB fails to start after upgrading from Platform 7 to Platform 8. EZBake controls which java we run with by setting JAVA_BIN to /usr/bin/java in our service defaults. On Debian and Redhat (at least), this is actually a symlink to java controlled by update-alternatives and alternatives respectively. RedHat's Java 8 package still has a higher alternatives priority than Java 11, so even though our PuppetDB 8 packages install java 11, the symlink at /usr/bin/java is not updated and we continue trying to use java 8. This breaks because HikariCP was updated to a version that does not run on java 8 anymore. It is also possible that we would hit this on Debian-based OSes on any installation where an admin has manually selected java 8. Add Comment

This message was sent by Atlassian Jira (v8.20.11#820011-sha1:0629dd8)

[Austin Blatt (Jira)]

Austin Blatt updated an issue

PuppetDB / PDB-5630 RHEL Platform 7 to Platform 8 upgrade failure

Change By: Austin Blatt

Problem: On RedHat-based OSes, PuppetDB fails to start after upgrading from Platform 7 to Platform 8. EZBake controls which java we run with by setting JAVA_BIN to /usr/bin/java in our service defaults. On Debian and Redhat (at least), this is actually a symlink to java controlled by update-alternatives and alternatives respectively. RedHat's Java 8 package still has a higher alternatives priority than Java 11, so even though our PuppetDB 8 packages install java 11, the symlink at /usr/bin/java is not updated and we continue trying to use java 8. This breaks because HikariCP was updated to a version that does not run on java 8 anymore. It is also possible that we would hit this on Debian-based OSes on any installation where an admin has manually selected java 8.

This does not affect PE because the hard-coded path in EZBake is to pe-java and not a java managed by update-alternatives. Option 1: Guide users through the problem manually with documentation. On RedHat, they could be instructed to install java 11 and select it as the preferred java. Con: module upgrades will not work without manual intervention. Option 2: We can use the output of the alternatives cli tools to "sniff" out available java versions and select one that will work for us even if the user has an incompatible java selected as the default java. In this case we would remove EZBake's hard-coded JAVA_BIN setting, but allow users to override the sniffing by setting JAVA_BIN themselves (this will also maintain their ability to use a java that is not registered with the alternatives programs. Open questions: SLES?

Add Comment

[Rob Browning (Jira)]

Rob Browning updated an issue

PuppetDB / PDB-5630 RHEL Platform 7 to Platform 8 upgrade failure

Change By: Rob Browning

Problem: On RedHat-based OSes, PuppetDB fails to start after upgrading from Platform 7 to Platform 8. EZBake controls which java we run with by setting JAVA_BIN to /usr/bin/java in our service defaults. On Debian and Redhat (at least), this is actually a symlink to java controlled by update-alternatives and alternatives respectively. RedHat's Java 8 package still has a higher alternatives priority than Java 11, so even though our PuppetDB 8 packages install java 11, the symlink at /usr/bin/java is not updated and we continue trying to use java 8. This breaks because HikariCP was updated to a version that does not run on java 8 anymore. It is also possible that we would hit this on Debian-based OSes on any installation where an admin has manually selected java 8. This does not affect PE because the hard-coded path in EZBake is to pe-java and not a java managed by update-alternatives. Option 1: Guide users through the problem manually with documentation. On RedHat, they could be instructed to install java 11 and select it as the preferred java. Con: module upgrades will not work without manual intervention.

Option 2: We can use the output of the alternatives cli tools to "sniff" out available java versions and select one that will work for us even if the user has an incompatible java selected as the default java. In this case we would remove EZBake's current /etc/default/PACKAGE hard-coded JAVA_BIN =/usr/bin/java setting, but still allow users to set that there to override the sniffing by setting JAVA_BIN themselves auto-detection (this will also maintain their ability to use a java that is not registered with the alternatives programs. Open questions: SLES?

Add Comment

[Rob Browning (Jira)]

Rob Browning updated an issue

PuppetDB / PDB-5630 RHEL Platform 7 to Platform 8 upgrade failure Change By: Rob Browning

Problem: On RedHat-based OSes, PuppetDB fails to start after upgrading from Platform 7 to Platform 8. EZBake controls which java we run with by setting JAVA_BIN to /usr/bin/java in our service defaults. On Debian and Redhat (at least), this is actually a symlink to java controlled by update-alternatives and alternatives respectively. RedHat's Java 8 package still has a higher alternatives priority than Java 11, so even though our PuppetDB 8 packages install java 11, the symlink at /usr/bin/java is not updated and we continue trying to use java 8. This breaks because HikariCP was updated to a version that does not run on java 8 anymore. It is also possible that we would hit this on Debian-based OSes on any installation where an admin has manually selected java 8. This does not affect PE because the hard-coded path in EZBake is to pe-java and not a java managed by update-alternatives. Option 1: Guide users through the problem manually with documentation. On RedHat, they could be instructed to install java 11 and select it as the preferred java. Con: module upgrades will not work without manual intervention.

Option 2: We can use the output of the alternatives cli tools to "sniff" out available java versions and select one that will work for us even if the user has an incompatible java selected as the default java. In this case we would remove EZBake's current /etc/default/PACKAGE hard-coded JAVA_BIN=/usr/bin/java setting, but we'd still allow users to set that JAVA_BIN there to override the auto-detection (this will also maintain their ability to use a java that is not registered with the alternatives programs. Open questions: SLES?

Add Comment

[Austin Blatt (Jira)]

Austin Blatt assigned an issue to Rob Browning

PuppetDB / PDB-5630 RHEL Platform 7 to Platform 8 upgrade failure

Change By: Austin Blatt Assignee: Rob Browning

Add Comment

[Austin Blatt (Jira)]

Austin Blatt assigned an issue to Austin Blatt

PuppetDB / PDB-5630 RHEL Platform 7 to Platform 8 upgrade failure

Change By: Austin Blatt Assignee: Rob Browning Austin Blatt

Add Comment