Adapting templates to state of 8.7.1 tarball, while keeping required … #329
Conversation
…modifications in place. Fixes voxpupuli#300.
|
closes #317 |
SimonHoenscheid
changed the title
|
tested with current version, for backwards compat, there should be a diffrent template for lower versions. @timdeluxe do you know which version changed the files? |
SimonHoenscheid
changed the title
Not really, i am sorry. I just took the 8.7.1 state and tried to adapt it as smartly as possible |
| # For Java 11 and relatively small heaps we recommend: -XX:+UseParallelGC | ||
| # For Java 11 and larger heaps we recommend: -XX:+UseG1GC -XX:+ExplicitGCInvokesConcurrent | ||
| # | ||
| JVM_GC_ARGS="-XX:+ExplicitGCInvokesConcurrent" |
There was a problem hiding this comment.
shouldn't this be behind a check which version of java we're on?
see discussion here: #326
There was a problem hiding this comment.
Well, we would need to decide how.
Either we put a dependency to the puppetlabs-java module and use its facts. However this adds a whole module to be aware of, just for that "little" fact. Many users use it to install the needed Javas (like we do), but not all i would guess.
Another option would be a custom fact to this module which should have a special name like "...jira_java..." or so to not conflict with the facts of puppetlabs-java (for the people who use that module to install the needed java). Code could be copied from puppetlabs-java. This could also have the advantage of checking the java with the user, which will actually run Jira.
Or we leave it completely up to configuration with a required variable somewhat like discussed in #326 , forcing the user to set it, but that is no smart way in my opinion.
Any opinions/favourites?
There was a problem hiding this comment.
can we try use the facts without depending on it?
we'd have to do it defensively, but so does every module which relies on facts that are only available after the software has been installed, i.e.: after it was run, so it's not like we'd be breaking new ground here
There was a problem hiding this comment.
@igalic I dont get you completely. You mean to use the facts from puppetlabs-java, but without setting the dependencies in metadata.json? That is not smart in my opinion, because then we would need to tell in the documentation, that for proper JVM_GC_ARGS variables one needs to install puppetlabs-java.
There is another thing: #326 was created, because Java 11 does not like "PrintGCTimeStamps", however "PrintGCTimeStamps" is not in the upstream code anymore for Jira 8.7.1. If we want to be downwards-compatible with older Jira version, we have a problem. Alternative could be that we say, the new release of the module is only compatible with Jira 8.7.1 and newer. Or we remove the "PrintGCTimeStamps" also for older Jira releases.
Also java version check is not enough, for java 11 we might need to compare the value of jira::jvm_xmx also.
My proposals would be the following:
- introduce a custom fact for the java version in this module (no dependencies required then)
- make parameter similar to Make JVM_EXTRA_ARGS manageable for java 11 compatibility #326, but default value is empty
- if previous mentioned parameter is empty, set value depending on custom fact and jira::jvm_xmx value. If not empty use the value of the parameter
- set "PrintGCTimeStamps" only for Jira Versions < 8 or alternatively check setenv.sh of every jira release from 7.x until 8.7 to see, when they really removed it
There was a problem hiding this comment.
I would also put the following in consideration: which Jira versions are still supported and which Java versions are supported by these versions? Write this in the documentation. Going for the smallest commonality. I am fine with depending on puppetlabs-java and would write documentation for it.
There was a problem hiding this comment.
Jira 7.12 to 8.12 is supported, 7.12 only has support for OracleJava 8, 7.13 to 8.1 have support for Oracle & OpenJDK8. 8.2 Onwards has Java11 support.
Here are the EOL Dates:
8.1 (EOL Date: Apr 4, 2021)
8.0 (EOL Date: Feb 11, 2021)
7.13 (EOL Date: Nov 28, 2020)
7.12 (EOL Date: Aug 27, 2020)
Since 7.12 just dropped out of support, it's much easier to maintain, because openJDK/JRE is always available
There was a problem hiding this comment.
@timdeluxe, @SimonHoenscheid In #326 I've added the 'jvm_type' parameter, which can be set to the used JVM version, which is used in setenv.sh and other configurations.
The current changes in #326 tackle the following aspects of your comment:
introduce a custom fact for the java version in this module (no dependencies required then)
make parameter similar to #326, but default value is empty
As you asked, I've set the default to 'oracle-jdk-1.8' and left the default parameters for jvm_optional, jvm_extra_args, jvm_gc_args, jvm_codecache_args empty. If someone chooses to use JDK 11, the jvm type can be set to openjdk-11 or even to custom if parameters don't line up.
I wonder if we would need to add something like "jvm_gc_args_additional" variables, so that someone who chooses a 'jvm type != custom' does not need to fallback to custom if one parameter needs to be adjusted. I've put that one into my PR #326 as well, including a test. Another option would be, that we add the 'jvm_*' args if they are not empty and the jvm_type points to something default like 'oracle-jdk-1.8'. What do you think?
if previous mentioned parameter is empty, set value depending on custom fact and jira::jvm_xmx value. If not empty use the value of the parameter
I think, leaving the jvm_type parameter empty is too much implicit behavior. If someone wants custom parameters to be set the behavior should be explicitly defined.
set "PrintGCTimeStamps" only for Jira Versions < 8 or alternatively check setenv.sh of every jira release from 7.x until 8.7 to see, when they really removed it
The PrintGCTimeStamps is a java parameter, it shouldn't be judged by the jira version.
I am very confused about all the loose ends and the many PRs now existing. I tried to dig through them and this is my conclusion: #334 includes #341 and is green, while #341 is not. #326 is already merged and a good idea to solve the java version topic. #326 makes template/setenv.sh.erb part of #329 and #317 invalid/obsolete. The only thing left is to update templates/check-java.sh.erb and templates/server.xml.erb to reflect current state of original jira tar file. The changes there should be backwards compatible with older jira (7.x) and java versions (8.x). The changes to both files are identical in #329 and #317, so we just need someone to decide if @SimonHoenscheid updates his PR or i update mine (update = drop our changes to setenv.sh.erb in favor of the master state updated by #326). Depending on the decision the other PR should be dropped (closed unmerged). In case my conclusion is not completely wrong: Can someone roll the dice? :D |
|
@timdeluxe if it doesn't matter, whoever updates their PR first can have it merged. |
|
I just did a rather large conversion of ERB templates into EPP in #354. I can take a look at updating server.xml etc after that's merged, but I'd prefer not to work with ERB... |
|
@timdeluxe I'll double-check that server.xml matches upstream eventually anyway. I'll close this PR since rebasing it is probably more work than necessary with all the other things being shuffled around. Once I'm done with doing the changes I feel need to be done, I'll try to give it some time for anyone interested to suggest adjustments before any API changes become finalized by a release. |
Pull Request (PR) description
This adapts the templates for java-check, server.xml and setenv to the state of the 8.7.1 tarball, while keeping required modifications in place.
I thought about setting stuff depending on the installed java version, however not everyone installs java also via puppet and if ones does it, it must not necessarily be via the java puppet module.
Maybe we need an additional parameter to the module stating the java version?
This Pull Request (PR) fixes the following issues
Fixes #300