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

Warning unknown variable 'staged_package' when yum is used as package provider #169

Open
rmestrum opened this issue Jan 29, 2018 · 6 comments
Labels
bug Something isn't working

Comments

@rmestrum
Copy link

Affected Puppet, Ruby, OS and module versions/distributions

  • Puppet 4.10.8:
  • Ruby: 2.1.9p490
  • Distribution: RHEL 6.7
  • Module version: 7.1.0

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

  class {'::splunk::forwarder':
    pkg_provider => 'yum',
  }

What are you seeing

Puppet gives the following warning:

Warning: Unknown variable: 'staged_package'. at /etc/puppetlabs/code/environments/production/modules/splunk/manifests/forwarder.pp:93:28

What behaviour did you expect instead

No warning.

Output log

Any additional information you'd like to impart

@bastelfreak
Copy link
Member

Hi, thanks for rising this bug. Interesting that it is unknown. I am not quite sure how that is possible. Do you call any other class of the splunk module as well?

@bastelfreak bastelfreak added the bug Something isn't working label Jan 29, 2018
@rmestrum
Copy link
Author

I only use this class since we only install the splunk forwarder.

@bastelfreak
Copy link
Member

@TraGicCode can you take a look please? Any idea?

@TraGicCode
Copy link
Contributor

@bastelfreak I'm actually noticing this on my puppetserver as well ( which is ubuntu ). We should be able to throw together some rspec-puppet tests to reproduce this and hopefully pinpoint and fix the bug. Unfortunately i cannot look at this at the moment as things are very very busy for me with work since we have a huge migration project. I can try and look at this when i get the chance.

@TraGicCode
Copy link
Contributor

It looks like the cause of this is seems to be happening in this giant mess.

#no need for staging the source if we have yum or apt
if $pkg_provider != undef and $pkg_provider != 'yum' and $pkg_provider != 'apt' and $pkg_provider != 'chocolatey' {
include ::archive::staging
$src_pkg_filename = basename($package_source)
$pkg_path_parts = [$archive::path, $staging_subdir, $src_pkg_filename]
$staged_package = join($pkg_path_parts, $path_delimiter)
archive { $staged_package:
source => $package_source,
extract => false,
before => Package[$package_name],
}
}
Package {
source => $pkg_provider ? {
'chocolatey' => undef,
default => pick($staged_package, $package_source),
},
}

  1. The conditional there says if package provider is != yum then don't execute the code in the conditional.
  2. Below the conditional you see some package resource defaults being set. It essentially says if the package provider is not chocolatey then assume the installer for splunk-forwarder is going to come from a downloaded file from the archive resource ( which didn't happen based on the conditional )

This whole mess really need to be cleaned up.

Also inside the params.pp there is some code that really bothers me. It's trying to pick the default package provider based on the node's o/s family fact. This should work on deciding the "default" should be done automatically by the package provider implementations provided by puppet.

case $::osfamily {
'RedHat': { $pkg_provider = 'rpm' }
'Debian': { $pkg_provider = 'dpkg' }
'Solaris': { $pkg_provider = 'sun' }
default: { $pkg_provider = undef } # Don't define a $pkg_provider
}

Summary:

There needs to be a refactoring done to unravel this mess and prevent this fragile stuff from breaking in the future.

@treydock
Copy link
Contributor

Just to add, the only way I could get Windows to actually install was like so:

splunk::params::version: '7.0.2'
splunk::params::build: 03bbabbd5c0f
splunk::forwarder::pkg_provider: windows
splunk::forwarder::splunk_user: 'Administrator'

I wanted to use Chocolatey but didn't actually seem possible given the conditions in module. The above forced archive type to download package and install.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

4 participants