On Jan 8, 2009, at 6:17 PM, chakkerz wrote:
>
> Hello there
>
> I've been advised to do modules instead of massive class files. Sounds
> fine and based on http://reductivelabs.com/trac/puppet/wiki/ModuleOrganisation
> i've got:
> [r...@puppetbeta puppet]# pwd
> /etc/puppet
> [r...@puppetbeta puppet]# find
> .
> ./puppet.conf
> ./fileserver.conf
> ./modules
> ./modules/cust
> ./modules/cust/plugins
> ./modules/cust/plugins/facter
> ./modules/cust/plugins/facter/deploy_sudoers.rb
> ./modules/cust/plugins/puppet
> ./modules/cust/plugins/puppet/type
> ./modules/cust/plugins/puppet/provider
> ./modules/sudoers_linux
> ./modules/sudoers_linux/depends
> ./modules/sudoers_linux/files
> ./modules/sudoers_linux/templates
> ./modules/sudoers_linux/manifests
> ./modules/sudoers_linux/manifests/init.pp
> ./manifests
> ./manifests/site.pp
> ./manifests/nodes.pp
> ./manifests/classes
> ./manifests/classes/solaris.classes
> ./manifests/classes/freebsd.classes
> ./manifests/classes/linux.classes
> ./manifests/classes/shared.classes
>
> and thus my linux class looks like:
>
> import "sudoers_linux"
>
> class linux_default
> {
> include sudoers_linux
> }
>
> i tried 'import "*_linux" ' but it didn't like that. Now i understand
> that ./modules/<module name> is hardcoded (i could be wrong?) so how
> can i put the linux modules into a linux area?
>
> I realize i'm probably dense, and my example is a bit contrived, but i
> don't want the mess cfengine has become so i want the OSs
> separated... :)
>
> Any thoughts appreciated
I think this is generally the wrong approach. Obvious there will be
times where it makes sense, but usually you want a single module for
each service, and then within that module you do all work related to
the service. If you need to provide platform agnosticism, there are
two main approaches:
1 - Inline multiple platform support
Puppet has multiple ways of providing support for different platforms
in the same class. For instance:
file { "/etc/sudoers":
source => $operatingsystem {
debian => "...",
solaris => "...",
}
}
If you're using templates, then your templates can have builtin
support for multiple platforms. You can also use larger conditionals;
just wrap a case statement around the different chunks.
2 - Platform agnosticism through subclassing
Have a base class, 'sudo', that does the main work, and then have a
per-platform subclass, 'sudo::linux', that provides any necessary
tuning via overrides.
Really, though, the inline method is best, IMO. I mostly use
subclasses for modifications of the service -- e.g., a specific style
of deploying that app.
Make sense?
--
Sabbagh's Second Law:
The biggest problem with communication is the illusion that it
has occurred.
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
