Add support for log4j2.properties and unused parameters become deprecated (daily_rolling_date_pattern , default_logging_level, file_rolling_type, logging_file, logging_level, logging_template, deprecation_logging, deprecation_logging_level, rolling_file_max_backup_index, rolling_file_max_file_size, security_logging_content, security_logging_source)

[phaedriel]

Pull Request (PR) description

• Add indication deprecated parameters (if not used) : daily_rolling_date_pattern, default_logging_level , file_rolling_type, logging_file, logging_level, logging_template, deprecation_logging, deprecation_logging_level, rolling_file_max_backup_index, rolling_file_max_file_size, security_logging_content, security_logging_source
• Suppress template log4j2.properties.erb
• Modify manifest config.pp
• Add function ruby es_hash2properties

This Pull Request (PR) fixes the following issues

• Fixes log4j config, how to add custom appender #529
• Fixes Same template for both logging.yml and log4j2.properties #907
• Fixes ESJsonLayout as layout type #1056

Replace Opened PR

• Add node name to log4j config #1021
• update log4j2properties.erb for [%node_name]%markers  #1071

[smortex]

@phaedriel thanks for this PR!

Just to be sure, this should be tagged as a breaking change? Can you reword the PR title so that it "speaks" to end-user when they read the ChangeLog (which use the PR title and link to it for further details)?

Thanks!

[phaedriel]

@phaedriel thanks for this PR!

Just to be sure, this should be tagged as a breaking change? Can you reword the PR title so that it "speaks" to end-user when they read the ChangeLog (which use the PR title and link to it for further details)?

Thanks!

Better ?

I have keep unused parameters, just move them on bottom list and add optional if necessary > remove them will be more easy in future release.
I have clean unused values in data yaml files.

I'm not sure it's a breaking change ?

[smortex]

Better ?

Thanks!

I have keep unused parameters, just move them on bottom list and add optional if necessary > remove them will be more easy in future release. I have clean unused values in data yaml files.

I saw, and its awesome 😍

I'm not sure it's a breaking change ?

I used an old version of the module (ES 6.x, when the module was managing multiple instances) and it seems it managed log4j2.properties. But looking at the changes, it seems it stopped doing so, so that's why I am asking.

If I am right, this in an "enhancement" (it add a new feature: previously in this major branch the file could not be managed and now it can be). But if I update from a previous version (same major version, let's say the latest version 8.0.2), if it will change the content of the file it is a breaking change (I don't think we are in this case). Maybe the user could have some settings in logging_config that where ignored and will be applied again, this is not a breaking change, at most it is an enhancement, and someone can argue it is a bugfix :-)