[Mageia-sysadm] Questions about puppet config

[sebelee at free.fr]

After regarding a little bit the puppet configuration, I have some questions about the current puppet configuration.


1) Why using both subscribe() and notify() metaparameters ?

If i'm not mistaken a "file resource" notify a "service", or a "service" subscribe to a "file ressource" : the result are already the same.
As you say puppet is a little bit too intimidating and in order to be more easy, can we perhaps use only one method ?

For example change all subscribe() calling ?

-----------------------------
modules/ntp/manifests/init.pp
-----------------------------
class ntp {

    package { ntp: 
        ensure => installed
    }

    service { ntpd:
        ensure => running,
        path => "/etc/init.d/ntpd",
    }
    
    file { "ntp.conf":
        path => "/etc/ntp.conf",
        ensure => present,
        owner => root,
        group => root,
        mode => 644,
        require => Package["ntp"],
        content => template("ntp/ntp.conf"),
	notify => Service["ntpd"],
    }
}


 
2) In the same idea, after reading the beginning of the book "Pro Puppet", the author describes a sort of Best Pratice for managing puppet's module.

The book extract :
<< In Listing 2-2, we created a functional structure by dividing the components of the service we're managing into functional domains: things to be installed, things to be configured and things to be executed or run. >>

He also split a module in 3 files and include all of them into init.pp
- manifests/install.pp  
- manifests/config.pp   
- manifests/service.pp 


For example with the ntp service : 

--------------------------------
modules/ntp/manifests/install.pp
--------------------------------
class ntp::install {
    package { "ntp": 
        ensure => installed
    }
}

--------------------------------
modules/ntp/manifests/config.pp
--------------------------------
class ntp::config {
    file { "ntp.conf":
        path => "/etc/ntp.conf",
        ensure => present,
        owner => root,
        group => root,
        mode => 644,
        content => template("ntp/ntp.conf"),
        require => Class["ntp::install"],
 	notify => Class["ntp::service"],
    }
}

--------------------------------
modules/ntp/manifests/service.pp
--------------------------------
class ntp::service {
    service { "ntpd":
        ensure => running,
        path => "/etc/init.d/ntpd",
    }
}

-----------------------------
modules/ntp/manifests/init.pp
-----------------------------
class ntp {
    include ntp::install, ntp::config, ntp::service
}


Also we have the same logical, a "config ressource"
- need a "install ressource" (packages) 
- and notify a "service"



3) With this schema, we can also classify specials functionnalites or class by creating one or more extra file(s) 

  a) for example for the "define vhost_redirect_ssl" in apache module
 
   ----------------------------------
   modules/apache/manifests/vhosts.pp
   ----------------------------------
   ...
    define apache::vhost_redirect_ssl() {
        vhost_base { "redirect_ssl_$name":
            vhost => $name,
            content => template("apache/vhost_ssl_redirect.conf")
        }
    }
    ...



   b) or for make differences between tasks, example for cronjobs

   ------------------------------------
   deployement/common/manifests/cron.pp
   ------------------------------------
   class common::urpmi_update {
      cron { urpmi_update:
             user => root,
             hour => '*/4',
             minute => 0,
             command => "/usr/sbin/urpmi.update -a -q",
      }
   }



I'm just a beginner with puppet and I don't know if this a method can work for a production environnement day after day...
But i think instead of having all the module's classes in a same file, split them into specifics items would be more easy for understanding and also give more granularity.


What do you thing about this approach ?

--
Sébastien Kurtzemann