John,
I'm running into some snags of my own and your explanations have been
helpful. However, I'd like to ask if you can comment a bit more on the
emphasis Puppet Labs has on parameterized classes versus include. For one,
I'm thinking of modules available via github. Take the
puppetlabs/mcollective module, for example. It's highly parameterized and I
have some "wrapper classes" like this:
class puppet_base ( $puppet_master = false, $mcollective_client = false
) {
class { 'system_base': } # basics needed by all systems
class { 'puppet':
master => $puppet_master,
require => Class['system_base'],
}
class { 'mcollective_server':
mcollective_client => $mcollective_client,
}
}
class mcollective_server ( $mcollective_client => false ) {
package { 'stomp':
ensure => present,
provider => 'gem',
}
if $mcollective_client {
class { 'activemq':
require => Package['stomp'],
before => Class['mcollective'],
}
}
class { 'mcollective': # puppetlabs/mcollective module
client => $mcollective_client,
}
}
This seemed to me like an appropriate use of parameterized classes and a
way of keeping node definitions simple and readable, like so:
node 'regular-host' {
class { 'puppet_base':
stage => 'first'
}
}
node 'mco-admin-host': {
class { 'puppet_base':
stage => 'first',
mcollective_client => true,
}
}
node 'puppet-master' {
class { 'puppet_base':
stage => 'first',
puppet_master => true,
}
}
I am running into some snags with ensuring curl and rubygems packages are
installed prior to the puppet_base being evaluated (that's a long story),
but that may be more of an issue with better use of stages.
Can you comment on the above and how it is impacted by your explanations of
includes (and smarter classes) vs. parameterization?
Thanks,
Justin
On Tue, Mar 6, 2012 at 8:50 AM, jcbollinger <john.bollin...@stjude.org>wrote:
>
>
> On Mar 6, 8:51 am, "chris_sny...@sra.com" <chris_sny...@sra.com>
> wrote:
> > Crap. I'm trying to dump Bcfg2 and move to something reasonable. But so
> > far, all my initial assumptions and patterns for Puppet fail. I think in
> > terms of heirarchy and inheritence for my systems (all nodes install a
> core
> > set of packages, some have exceptions for those core set of packages,
> etc)
> > and as best as I can understand it Puppet's DSL really wants me to
> create a
> > set of flat, non-hierarchial, non-inheritable set of nodes/classes. And
> for
> > me that's completely un-managable.
> >
> > I'm reviewing the Puppet-user archives now and I'm seeing a lot of people
> > with similar problems but no good patterns for solutions.
> >
> > I want to be able do something like this (hierarchial, inheritance with
> > overloading):
> >
> > class base {
> > package { 'sshd' : ensure => present }
> > package {'ntp: ensure => present }
> >
> > }
> >
> > node a,b,c {
> > class { 'base' : }
> >
> > }
> >
> > node d {
> > class { 'base' : }
> > Package{'sshd': ensure => false }
> >
> > }
> >
> > What I'm afraid I have to do is this (flat, redefine lots of nodes and
> > duplicate data):
> >
> > class base
> > package {'ntp: ensure => present }
> > # More common packages defined
> >
> > }
> >
> > node a,b,c {
> > class { 'base' : }
> > package { 'sshd' : ensure => present }
> >
> > }
> >
> > node d {
> > class { 'base' : }
> > package { 'sshd' : ensure => false}
> >
> > }
> >
> > or worse (sometype of parameter passing in the worst, un-managable way):
> >
> > class base ( # list ever possible ensure parameter, etc ) {
> > package { 'sshd' : ensure => $ssh_ensure }
> > package {'ntp: ensure => $ntp_ensure }
> > # More common packages defined
> >
> > }
> >
> > node a,b,c {
> > class { 'base' : }}
> >
> > }
> >
> > node d {
> > class { 'base' : ssh_ensure => false}
> >
> > }
> >
> > I'm open to any and all suggestions.
>
>
> Surprisingly, you have named one of the few types of problems for
> which Puppet's class inheritance offers a reasonable solution:
>
> class ssh {
> package { 'sshd': ensure => 'present' }
> }
>
> class ssh::absent inherits ssh {
> Package[ 'sshd' ] { ensure => 'absent' }
> }
>
> node default {
> include 'sshd'
> }
>
> node d inherits default {
> include 'ssh::absent'
> # no problem that class ssh is also declared
> }
>
>
> All the same, a more forward-looking, probably better solution would
> be to rely on hierarchical data instead of hierarchical nodes and
> classes. Using the 'hiera' module recently adopted into Puppet, you
> could achieve the same effect via just
>
> class ssh {
> package { 'sshd': ensure => hiera('sshd_ensure') }
> }
>
> node default {
> include 'sshd'
> }
>
> CAVEAT: hiera configuration and data not shown. It isn't hard to set
> up and use, but it isn't automagical, either.
>
>
> John
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
>
--
“We don’t need to increase our goods nearly as much as we need to scale
down our wants. Not wanting something is as good as possessing it.” --
Donald Horban
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
