Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to disable archive creation in splunk::forwarder. #319

Open
gcoxmoz opened this issue Sep 2, 2021 · 0 comments
Open

Unable to disable archive creation in splunk::forwarder. #319

gcoxmoz opened this issue Sep 2, 2021 · 0 comments

Comments

@gcoxmoz
Copy link
Contributor

gcoxmoz commented Sep 2, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant