TAPP: Splunk domeger/splunk-uf-universal module review

domeger/splunk-uf-universal

Adherence to Puppet Style
- Please review the Puppet Style Guide
- For instance, alignment of hash rockets
Puppet types have weak to no validation
- Should bolster your types by providing constraints on user provided data and conformance standards
Puppet manifest classes are not documented in known standards
- puppet describe face depends on Puppet strings style of documentation
  - Reference: Puppet strings
  - Example: init.pp from puppetlabs/ntp
Data types should be used for parameters in Puppet DSL classes
- Data types
- Abstract data types
Puppet DSL should contain data validation
- Should provide proper validation of data provided by module users
  - Use data types where possible as this will provide basic validation
  - Provide additonal validation via custom functions
    - Example: validate_ipaddress

README should be written out to follow a similar style used by Puppet
- Example: puppetlabs/ntp/README.MD

Conditional logic should be used to determine which package is suitable for which OS
- Common use of $facts['os']['family'] fact can be used to determine package type
Data types should be used for parameters in Puppet DSL classes
- Data types
- Abstract data types
Hardcoded values can make module inflexible
- Considering exposing values (i.e., file paths) where possible to allow for flexibility

Explicit hiera lookups not required
- Exposure of parameters causes Hiera to automatically lookup key
Conditional logic should be use to determine if OS is systemd vs SysV
- Comparison of $facts['os']['family'] and $facts['os']['release']['full'] will work
- Custom function also suitable
No validation
- Should provide proper validation of data provided by module users
  - Use data types where possible
  - Provide additional validation via custom functions
    - Example: validate_ipaddress
Data types should be used for parameters in Puppet DSL classes
- Data types
- Abstract data types