Default JDK versions are out of date

[wcooley]

The default JDK versions are for 1.6; Rundeck has required 1.7 since at least 2.4, released in December. (I didn't look back further.) The service fails to start when only 1.6 is installed.

[ozbillwang]

Could you set in hiera yaml file to control the jre/jdk version? With this way, you can control the version by yourself, even to install rundeck with java 8.

jre_name

The name of the jre to be installed if using a custom jre.

[wcooley]

Sure, it can be done either in Hiera or as a resource-style class declaration with the parameter; doesn't change the fact that the hard-coded default is no longer current.

I'm undecided about whether trying to track versions like this is a good idea or not -- on the one hand, it requires maintaining a version compatibility mapping that will require maintenance; on the other hand, it's really great for things to just work out of the box.

But resolving that is someone else's call; since it's there now, it should be correct.

[ozbillwang]

My view for this issue is, it is not issue.

Many sites are still using rundeck version of 1.5.X and 1.6.X, update to java 7 is not 100% correct.

[liamjbennett]

We should be able to support this without breaking backwards compatibility with people running with older versions.

I do think that it's important to continue to support to most basic use-case where everything works out of the box.

[igalic]

our jira, stash and confluence modules have established a pattern for tracking the version through facts. (this makes upgrades really easy)

so if we do add a version compat matrix to this module, we should also track the installed version.

[ozbillwang]

@liamjbennett

I saw the new open pull request which have a lot of code changes.

But why make it so unnecessary complicated and spend time on it. The comments in manifests/init.pp has explained how to install rundeck with a custom jre. It is the end user who should know which java version should be installed with Rundeck.

# Installing rundeck with a custom jre:
#
# class { 'rundeck':
#   jre_name    => 'openjdk-7-jre',
#   jre_version => '7u51-2.4.4-0ubuntu0.12.04.2'
# }

[liamjbennett]

So you think it would be better to make those required parameters and bump a major version?

[ozbillwang]

@liamjbennett
That's my personal option. As my first reply, this issue is not issue from my view.

commits wcooley@4d9ba11 and wcooley@db406a1 have been merged, looks reasonable.

But commit 5b304fe goes too far away, it adds function, but not necessary.

[liamjbennett]

I have raised an alternative PR for this issue - that completely removes the management of the JRE.
The argument is this case is that it should probably be managed at the profile level and just documented in this module as a dependency.

Thoughts?

[wcooley]

I think not managing the JRE is probably fine - it's a big, messy piece that has lots of other interested parties, so leaving it up to the user is probably for the best. It would be a good idea (I haven't looked at your PR) to include externally managing the JRE in the examples (maybe using puppetlabs/java) -- that will make it more visible than just including it in a body of text.

[liamjbennett]

Removed the management of the JRE. Need to add many more examples into the documentation anyway before the next release but I will raise that as a separate PR.

Closing this issue now as it is no longer relevant. Thanks for pushing me forward to deal with this problem.