Puppet: Passing parameters through classes

Question

This is a follow on to my earlier question about parameterized classes. Following on that example a little further, I want to be able to pass running or stopped into the service, but when I add the service to a box, I don't use "include poodle::service", I use "include poodle" which does all of the other stuff Poodle requires to be installed.

So, can I pass the variable along to the service class like this:

# SITE.PP
node 'tweedle.example.com' {
    include basicstuff
    include poodle
}
node 'beetle.example.com' {
    include basicstuff
    class { 'poodle':
        $ensure => 'stopped'
    }
}

## POODLE MODULE, manifests/init.pp
class poodle ( $ensure = 'running' ) {
    class {'poodle::install': }
    class {'poodle::config': }
    class {'poodle::service': 
        ensure => $ensure
    }
    Class ['poodle::install'] -> Class ['poodle::config'] ~> Class ['poodle::service']
}

...

class poodle::service ( $ensure ) {
    service {'poodle':
        ensure     => $ensure,
        enable     => true,
        restart    => "/etc/init.d/poodle stop && sleep 5 && /etc/init.d/poodle start",
        subscribe  => File['/opt/poodle/poodle.py'],
    }
}

Or should I put the parameter directly on the service class and the explicitly call both the Poodle class and Poodle's service class like this:

# SITE.PP
node 'tweedle.example.com' {
    include basicstuff
    include poodle
}
node 'beetle.example.com' {
    include basicstuff
    include poodle
    class { 'poodle::service':
        $ensure => 'stopped'
    }
}

## POODLE MODULE, manifests/init.pp
class poodle {
    class {'poodle::install': }
    class {'poodle::config': }
    class {'poodle::service': 
        ensure => $ensure
    }
    Class ['poodle::install'] -> Class ['poodle::config'] ~> Class ['poodle::service']
}

...

class poodle::service ( $ensure = 'running') {
    service {'poodle':
        ensure     => $ensure,
        enable     => true,
        restart    => "/etc/init.d/poodle stop && sleep 5 && /etc/init.d/poodle start",
        subscribe  => File['/opt/poodle/poodle.py'],
    }
}

Or is adding the parameter to the service class and including ONLY that enough, because the service class has dependencies, like this:

# SITE.PP
node 'tweedle.example.com' {
    include basicstuff
    include poodle
}
node 'beetle.example.com' {
    include basicstuff
    class { 'poodle::service':
        $ensure => 'stopped'
    }
}

## POODLE MODULE, manifests/init.pp
class poodle {
    class {'poodle::install': }
    class {'poodle::config': }
    class {'poodle::service': 
        ensure => $ensure
    }
    Class ['poodle::install'] -> Class ['poodle::config'] ~> Class ['poodle::service']
}

...

class poodle::service ( $ensure = 'running') {
    service {'poodle':
        ensure     => $ensure,
        enable     => true,
        restart    => "/etc/init.d/poodle stop && sleep 5 && /etc/init.d/poodle start",
        subscribe  => File['/opt/poodle/poodle.py'],
    }
}

What is the right course and best practice here? Thanks in advance!

Answer 1

Generally, you don't want people to have to understand the internal structure of your module to use it.

I certainly wouldn't require them to include both poodle and poodle:service.

Modules usually follow one of two structures:

• Single entry point via init.pp for simple services with few/no params and no separate roles (client/server) or "multiples" (like a database server could have multiple db's configured in it via puppet)

• Multiple entry points via subclasses and defined types that handle separate roles and multiples

Based on what you've described, I would place the parameter in the main class and pass it through to the service subclass.

Answer 2

node 'beetle.example.com' {
    class { 'poodle::service':
        ensure => 'stopped'
    }
}

works.

But I disagree saying "you don't want people to have to understand the internal structure of your module" in that point that you want the flexibility when creating vhosts to define what port, protocol, what backend - proxy + and what modules etc. should be used. I don't see a way for my projects how to enable such flexibility by just writing include apache, nginx or such.