Puppet manifest design best practices for Satellite 6

Latest response

I am looking for a consistent way to write Puppet modules in such a way that from within Satellite, a user can enter Smart Class Parameters as an array of strings to add to a file. The goal is to have as generic as possible Puppet code to cover a wider range of scenarios with the data being entered mostly from Satellite. Before Satellite came into the picture I was doing this with Hiera with Puppet. For example, I'm trying to write a module to modify the syslog configuration file using the Puppet 'file_line' command from the Puppet stdlib module. I would like the parameter to be an array, and have the user enter the lines to be appended to syslog conf into that array, as a Smart Class Parameter. That way the same module can be used to add 1 line or 5, and this pattern can be used in modules for other purposes. I can't figure out how to do that in the confines of the the current version of Satellite.
Red Hat Satellite 6.1 comes with Puppet version 3.6.2. (4.4 is the latest version of Puppet right now).
Puppet 3.2 until 4.0 had an option to use the 'future parser' in puppet.conf. This introduced language features, like iteration, that are available in Puppet 4.
I can enable the future parser in my puppet.conf file on my Satellite server and use 'each' to iterate through an array, but that breaks other modules that were working fine without it. Plus, the Puppet documentation itself states that future parser is 'experimental' and 'not ready for production'. Without future parser iteration as is commonly known is impossible. I get errors about duplicate declarations because defines are being called with the same name for example an exec call.
I am at a loss on how to create flexible, reusable Puppet modules, using this older version of Puppet, within the Satellite infrastructure. I am trying to avoid having 10 different Puppet modules to manage the same file across 10 different projects.
I hope this makes sense. Has anyone else asked these questions and had some success in answering them?

EL
Log in to join the conversation

Responses

EL Community Member 92 points
15 April 2016 8:17 PM

I don't know if anyone has read my question but I did come up with one possible solution. Hopefully this will help someone or at least clarify what my question was about.
init.pp:

class sandbox {
    class { '::sandbox::install': }
}

params.pp:

class sandbox::params
{
    $myusers = {
        'dummy' => { 
            name    => 'dummy',
            comment => 'default user when myusers not overriden',
            gid     => 100 
        },
    }
}

install.pp:

class sandbox::install (
    $myusers    = $sandbox::params::myusers,
    ) inherits sandbox::params
{
    create_resources(user, $myusers)
}
# in RHS, ALWAYS OVERRIDE $myusers

Then from within Satellite:
- configure Puppet classes, select sandbox::install
- override the $myusers parameter in the Smart Class Parameters tab
- set the variable type to 'hash'
example parameter - here I should be able to add as many users as needed, including or excluding any type attributes.
I was doing this with Puppet and Hiera before Satellite 6, but don't know of any way to use Hiera with Satellite.

user1:
  name: hashusr1
  comment: hash user 1
  gid: 100
user2:
  name: hashusr2
  comment: hash user 2
  gid: 100
David Powles's picture Red Hat 25369 points
18 April 2016 7:07 AM

Thanks for letting us know how you resolved your issue, Eric!

Close

Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.