log4j2.properties.erb doesn't work for v5.2 and earlier

[kwstone14]

• Module version: Elasticsearch 5.2
• Puppet version: 4.6 on puppet masters, 4.10 on agent servers
• OS and version: RHEL7

Bug description

The path variables accepted in log4j2.properties by Elasticsearch changed in the transition between ES5.2 and 5.3. Starting with v6.0.0 of the elastic-elasticsearch module, log4j2.properties.erb uses the tags

${sys:es.logs.base_path}${sys:file.separator}${sys:es.logs.cluster_name}

Elasticsearch versions up to 5.2 use only

${sys:es.logs}

in their path specifications. If you run 6.0.0 of the puppet module, it will use the newer variables in log4j2.properties, but log4j2 in ES5.2 won't recognize them and will create subdirectories ${sys:es.logs.base_path}/${sys:file.separator}/${sys:es.logs.cluster_name}. It confuses log4j2, and as a result no logging occurs.

The README file says that this module works for Elasticsearch 2.x, 5.x and 6.x. Based on what I found, the current reality is that the module in its current state works for Elasticsearch 5.3 and above. Logging doesn't work for versions previous to that.

I've forked the module and created a feature branch that adds more logic to log4j2.properties.erb to use the older variables if the version of Elasticsearch is less than 5.3.0. I've started testing and run into some different problems that I won't go into here.

We could work around this problem by upgrading to ES5.3. But since the claim is that the puppet module works with 5.x, it seems that something should be done to make it work.

So I guess the question here is: If I were to complete the changes I described and submitted a pull request for it, would it be something that is likely to be accepted?

I looked for related issues and didn't find anything that specifically addressed this.

[tylerjl]

If the changes to make 5.2 work aren't too hairy, it might be okay to merge in, but I'm probably more inclined to just yank <= 5.2 support since that version of Elasticsearch isn't even supported any more. My experience so far with supporting both old and new versions in the module has been very problematic for all the differences between versions, and supporting a version of Elasticsearch that is itself unsupported upstream will probably just cause headaches down the road. I don't really know when a good time to drop support for those versions is other than when the go end-of-life in the first place.

[TJM]

If it becomes "too hairy" you can always have a "module version vs elasticsearch version" supported matrix, so you would know if you need to run ES 5.2 or earlier just make sure you are on 5.5.0 or earlier of the module or whatever. The trouble arises when someone has to support both old and new versions simultaneously, but I guess they will just have to use a separate puppet environment (branch in control-repo) to support that old ES server :)