Die notify Funktion von Puppet hat eine seltsame Eigenschaft, die ich persönlich wenig nachvollziehbar finde. Sie impliziert einen “before”-Zusammenhang zwischen der Resource, die benachrichtigt, und der benachrichtigten. Das führt zu unpraktischen Komplikationen. Der Versuch einer Herleitung:
service { “tomcat” : ensure => running }
file { “/etc/tomcat.conf” : notify => Service[“tomcat”] }
Das funktioniert bestens, und bedeutet, dass zuerst die file-Direktive abgearbeitet wird, und dann der Service. Darauf aufbauend kann ich mir sehr gut folgende Erweiterung vorstellen:
class { “deployment::basic_app_server” : }
file { “/etc/tomcat.conf” : notify => Service[“tomcat”] }
Nehmen wir an in “deployment::basic_app_server” werden einige zentrale Dinge geregelt, darunter auch der tomcat-Service. Die Absicht: Ich möchte mich darauf verlassen können, dass spezifische Module auf einem bestimmten Konfigurationsstand aufsetzen. Dafür wurden stages eigentlich erfunden (meines Erachtens nach), also erweitern wir zu:
stage { “preparation” : before => Stage[“main”] }
class { “deployment::basic_app_server” : stage => “preparation” }
file { “/etc/tomcat.conf” : notify => Service[“tomcat”] }
Und … bumm. Da notify eine “file-before-service” (da Service wie angenommen in deployment::basic_app_server konfiguriert wird) impliziert, aber die Stages eine “service-before-file”-Beziehung verlangen, geht das nicht. Schön ist das nicht, finde ich.