parameter naming for config $file* vs. $config*

[DavidS]

https://github.com/stdmod/puppet-elasticsearch/blob/master/manifests/init.pp#L46

I'm currently playing around myself with stuff in the stdmod arena and I'm uncomfortable with the $file param group. I'd change that to $config_* and $file to $config_path, to make it clearer what is managed here.

[alvagante]

Uhm,
2 different topics here:

• If to use something like file_path (or package_name) instead of file and package. Good reasons for both choices, but I see th trend is more to use the extended version (file_path), so we might converge on that.
• The base name of the main configration file. I'd keep the reference to the resource type (file) as is more coherent with other common parameters (package, service, user, exec...). Eventually we might prefer something like $config_file_ rather than $file_. Both only $config_ IMHO deviates from the resource_attribute pattern

[alvagante]

Also if we introduce config_file , there's some incoherency with the $service and $package parameters, as they don't have a specific prefix for the main resource .
Still the point about clearness of the parameter name (config or config_file is more descriptive for sure) need attention.

[DavidS]

I see that I was very unclear in my original message. In my little universe (which may be very biased, I grant) the module manages "the package", "the service" and "the configuration file", which leads to the package_ service_ and config_ prefixes. That two of them coincide with the underlying resource type is nice, but not the driving force.

The _path suffix, too, comes from a linguistic argument (coming from a non-native speaker): contrary to $package and $service, $config might be misinterpreted as "the actual configuration (content)", and thus needs a clarification.

Using $config_file_ as group, instead of $config_ is a nice improvement over adding the _path suffix.