jira service not restarted when changing systemd file

[decibelhertz]

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: 5.5.19
• Ruby: 2.4.9
• Distribution: CentOS 7
• Module version: 4.0.0

How to reproduce (e.g Puppet code you use)

Change $javahome

What are you seeing

I believe https://github.com/voxpupuli/puppet-jira/blob/master/manifests/service.pp#L41 should be notify, not before.

What behaviour did you expect instead

Change in JAVA_HOME env var should restart the service, not just refresh systemd.

Output log

--- /usr/lib/systemd/system/jira.service    2020-03-21 14:50:09.262413164 +0000
+++ /tmp/puppet-file20200421-29393-1ymoezr  2020-04-21 14:13:28.910008660 +0000
@@ -4,7 +4,7 @@

 [Service]
 Type=forking
-Environment="JAVA_HOME=/usr/java/jdk1.8.0_201-amd64/jre"
+Environment="JAVA_HOME=/usr/java/jdk8u252-b09-jre"
 PIDFile=/data/atlassian/jira/atlassian-jira-software-8.5.4-standalone/work/catalina.pid
 User=jiraadm
 ExecStart=/data/atlassian/jira/atlassian-jira-software-8.5.4-standalone/bin/start-jira.sh

Notice: /Stage[main]/Jira::Service/File[/usr/lib/systemd/system/jira.service]/content: content changed '{md5}34094cf1388a619351dceaa0d8c38c80' to '{md5}1ef056d186b6f755b24de503b2c5769d'
Info: /Stage[main]/Jira::Service/File[/usr/lib/systemd/system/jira.service]: Scheduling refresh of Exec[refresh_systemd]
Notice: /Stage[main]/Jira::Service/Exec[refresh_systemd]: Triggered 'refresh' from 1 event
Notice: Applied catalog in 5.80 seconds

Ran service jira status -l and found that the service was still running the old version of Java 8.

Any additional information you'd like to impart

Am converting from Oracle JDK to AdoptOpenJDK JRE and the JIRA service needed to be manually restarted. I think this can be avoided with a simple metaparameter change.

[dhoppe]

I think we should use ˋˋˋcamptocamp/systemdˋˋˋ. @bastelfreak Do you agree?

[decibelhertz]

I know you're not asking me, but will point out that it would be consistent with the Vox Pupuli Confluence module to do that... https://forge.puppet.com/puppet/confluence/dependencies

[dhoppe]

Sounds good. It looks like the Confluence module is a little bit smarter, because it does not restart by default.

• https://github.com/voxpupuli/puppet-confluence/commit/b0de32163502cce2109477ad344f32fc68a17486

Are you able to provide a pull request? That would be great.

[decibelhertz]

I'm willing to do a PR (are several PRs?).

Upon code review, there are some organizational issues that I think would help when doing so. My questions would be:

• Inheritance is a mess. Some classes inherit jira::params, some jira, some none. Since that problem touches the issue I am talking about, I'd be interested in cleaning that up. Any opposition to me doing that?
• Are you open to using Hiera and ditching params.pp? That would help with some of the above point. I don't have to, but I do think it would be cleaner to do so.
• The confluence module code for systemd uses a selector in a resource declaration, which is not best practice. Won't be reproducing that. That ok?

Of less interest, but will point out that I am willing to address while I working:

• This module uses both staging and archive. The former is deprecated. Do you want me to clean that up? I don't have to, but have been doing that in my own work and could add that in.
• The jira::facts class for sure does not catch modern Puppet Enterprise installs (looking for a fact that is no longer there), which is what I use. The non-Enterprise path is working to report facts, but since its defaulting to /usr/bin/env ruby for ruby, there is risk of odd performance if Puppet and rvm are being used on the same OS. Do you want me to clean up?
• jira::facts also uses a selector at https://github.com/voxpupuli/puppet-jira/blob/master/manifests/facts.pp#L23-L25 which is not best practice ... Do you want me to fix that too?

[oranenj]

I'm currently on a cleanup spree, so it's pretty likely I'll do something to fix this too until I run out of steam :P Let's see.