Custom package name #179
Custom package name #179
Conversation
|
Thanks for everything you've done on getting this working - it looks a little more involved than I imagined it would be. It looks like all that's left are a few style issues in the example files. Best I can tell, the changes shouldn't break anything for users that already have everything working - is that the case? Just trying to figure how to version everything once it's merge and it's time for a release. Thanks again! |
this change adds 3 new module parameters for package name control. the OSS and prerelease name calculation logic is modeled after the elastic/elastic_stack module and allows for management of the OSS variant of the filebeat repo/package. while the OSS/prerelease support only works for linux and windows, the arbitrary package name support works on all platforms. fixes #177
|
the changes are backwards compatible. the default values for the 3 new parameters are either the same as the previously internally configured ones ($package_name), or false, which causes most of the new logic to be simply ignored. the refactoring of the config.pp was necessary to remove the xpack settings from the configuration file, should it be undefined (technically the OSS version of filebeat does not complain about xpack configuration, but other OSS versions of elastic products usually do) the package name continues to be filebeat (with the exception of FreeBSD, where it is beats), if the $oss parameter is set to false (which is the default) the OSS repo can only be managed for $major_version 6+, since elastic does not provide one for the 5.x branch (i could not find one at least) |
when using the OSS repository, the package is named filebeat-oss; at least under linux and windows environments.
this PR adds support for the OSS apt and yum repositories, as well as a custom package name.
this behaviour is similar to the elastic puppet modules.
when setting the oss parameter to true under *BSD environments, the catalog will most likely fail, as there are no -oss variants of the beats packages. i chose not to emit a warning should this constellation arise as i assume the user knows what they are doing.
the config refactoring is not necessarily required, as the OSS variant of filebeat currently ignores the xpack config, should it be present. since other elastic products in their OSS variant complain when they are provided with xpack config, i chose to follow that principle and remove any undefined parameters from the configuration before writing it to the file.
fixes #177