Ok - I'll try to make it as simple as I can...
***Modules***
We define 3 types of modules (its just our internal definition):
1. host type - this module is the only class that the node would have and
its it primary function of the host (e.g. you can't use more than one host
type module in one node)
2. service modules - modules which are usually shared between different host
type modules (e.g. ssh, apache etc), one special module here is the
host-base which every host-type module inherits
3. site modules, these are site specific modules which only apply to a
certain location.
***Version Control***
we use tagging extensively - e.g. when a module is ready for testing, it is
being tagged, if everything is ready, its tagged again is production.
Tagging associate a version to the module - e.g. ssh_1.5
everyone can checkin stuff into the head, but unless they are not tagged,
they would only impact machines which are in the development environment
*** environments ***
environments can be defined per location, application or a mix of the two
for example, the environment global-puppetmasters would include the module
ssh_1.5, apache_1.0 ....
this allows each environment to use a different pretested state of each
module.
a configuration example:
module_dir { "/etc/puppet/env/global_puppetmaster":}
##### Stable service modules #####
modules { "PP-host-base": module => "host-base", site =>
"global_puppetmaster", type => "services", version => "0.12"}
modules { "PP-sudo": module => "sudo", site =>
"global_puppetmaster", type => "services", version => "0.1" }
modules { "PP-ssh": module => "ssh", site =>
"global_puppetmaster", type => "services", version => "0.1" }
modules { "PP-sendmail": module => "sendmail", site =>
"global_puppetmaster", type => "services", version => "0.14"}
modules { "PP-ldap": module => "ldap", site =>
"global_puppetmaster", type => "services", version => "0.11"}
modules { "PP-redhat": module => "redhat", site =>
"global_puppetmaster", type => "services", version => "0.12"}
modules { "PP-autofs": module => "autofs", site =>
"global_puppetmaster", type => "services", version => "0.1" }
modules { "PP-apache2": module => "apache2", site =>
"global_puppetmaster", type => "services", version => "0.1" }
modules { "PP-subversion":module => "subversion",site =>
"global_puppetmaster", type => "services", version => "0.11"}
modules { "PP-syslog-ng": module => "syslog-ng", site =>
"global_puppetmaster", type => "services", version => "0.11"}
modules { "PP-monit": module => "monit", site =>
"global_puppetmaster", type => "services", version => "0.1" }
modules { "PP-munin": module => "munin", site =>
"global_puppetmaster", type => "services", version => "0.1" }
#### stable host types modules #####
modules { "PP-puppetmaster": site => "global_puppetmaster", module
=> "host-puppetmaster", version => "0.21" }
}
using this syntax it creates all the necessary environment modules which
are basically links to the version of the "stable/testing" module.
all of this code is available freely at
http://github.com/ohadlevy/puppet-multipuppetmaster
cheers,
Ohad
On Fri, Jan 9, 2009 at 2:43 AM, Ben Beuchler <ins...@gmail.com> wrote:
>
> > since many times, a given node has uses many different modules (which are
> > managed by different people) we decided to tag our "stable" modules (e.g.
> > associate it with a version) and generate an environment out of tested
> > combination of the stable modules.
>
> Would you be willing to describe this process in a bit more detail?
>
> -Ben
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
