puppet-splunk icon indicating copy to clipboard operation
puppet-splunk copied to clipboard

Unable to disable archive creation in splunk::forwarder.

Open gcoxmoz opened this issue 4 years ago • 0 comments

Affected Puppet, Ruby, OS and module versions/distributions

  • Puppet: 6.24
  • Ruby:
  • Distribution: CentOS 7
  • Module version:

How to reproduce (e.g Puppet code you use)

  class { '::splunk::params':
    #server => $my_splunk_server,
  }

  class { '::splunk::forwarder':
    # We don't want the splunk module to manage the package archive and sources.
    # We do that ourselves, above, by realizing the repo.
    manage_package_source => false,
    package_provider      => undef,
    # And don't load in a bunch of configs we don't want:
    use_default_config    => false,
  }

What are you seeing

Error: Unable to fetch archive, the source parameter is nil. Error: /Stage[main]/Splunk::Forwarder::Install/Archive[/opt/staging/splunk/]/ensure: change from 'absent' to 'present' failed: Unable to fetch archive, the source parameter is nil.

What behaviour did you expect instead

Short version, "I don't want that archive created."

In splunk::forwarder::install, there's a stanza (edited):

  if $splunk::forwarder::package_provider and !($splunk::forwarder::package_provider in ['apt','chocolatey','yum']) {
    $_src_package_filename = basename($_package_source)
    $_package_path_parts   = [$splunk::forwarder::staging_dir, $_src_package_filename]
    $_staged_package       = join($_package_path_parts, $splunk::forwarder::path_delimiter)

    archive { $_staged_package:
      source  => $_package_source,

If there's a $splunk::forwarder::package_provider, and it's not apt/chocolatey/yum then you get the archive.

In splunk::forwarder, the declaration is:

  Optional[String[1]] $package_provider      = $splunk::params::package_provider,

Note here, if you pass in an explicit undef, it looks the same as a soft undef, and puppet will trot off to params and load in a value.

In splunk::params, package_provider is:

  case $facts['os']['family'] {
    'RedHat':  { $package_provider = 'rpm' }
    'Debian':  { $package_provider = 'dpkg' }
    'Solaris': { $package_provider = 'sun' }
    'Suse':    { $package_provider = 'rpm' }
    'FreeBSD': { $package_provider = 'pkgng' }
    'windows': { $package_provider = 'windows' }
    default:   { $package_provider = undef } # Don't define a $package_provider

Being CentOS / RH, I am 'rpm' and have no means of altering that calculation.

So, first thing, this feels like a disconnect - splunk::forwarder::install is considering yum rather than rpm. Those are almost interchangeable parlance in my head, and I didn't even notice it until writing this bug. It's very unexpected to me. I would consider this either a bug, or a very surprising undocumented method, if one considers rpm different from yum since else nowhere in the module says yum.

Second, I can't pass in undef and expect it to mean "no really, NO package_provider" since it gets overriden by params which always succeeds. i.e there's there's no un-truthy value other than undef that satisfies Optional[String[1]].

I feel like the fix is one of:

  1. a simple s/yum/rpm/ in splunk::forwarder::install (and its tests),
  2. a doc fix ala I know it's weird but you really need to say "package_provider = 'yum'" to distinguish from 'rpm' and here's why, or
  3. a feature-exact parameter ala Boolean $use_archive = true so one can explicitly disable the archive area rather than rely on the undef thing.

I'm unclear on the intentions here, so I don't have a patch to offer, but they seem simple to write if we knew the intentions that got us here.

gcoxmoz avatar Sep 02 '21 15:09 gcoxmoz