Thanks for the info re the service command- makes life easier ;-) Also http://serverfault.com/questions/40156/puppet-force-service-restart-after-configuration-file-was-modified was useful-- how to use 'subscribe' with 'service' to ensure a service is restarted when a change to a configuration file is detected.
First time I read your answers I thought puppet was not going to be usable for what we want, but I think we had some misunderstandings. And sorry, yes, well aware it's pull not push- my bad. I specifically want to use the RPM provider, not the yum provider. Otherwise (as I understand it) I will have to set up a yum repository for each machine (or at least environment), and updating/rolling back our app will be more complicated than I want to deal with. ie I don't want an inadvertent 'yum update' changing the version of our application. Pulling explicit RPMs via puppet seems easier to control right now. Eg we can store the manifests in svn and have an explicit record of application versions installed at a given point in time/for a given environment. If we use yum, I'll have to manage several yum repos, including checking in the generated indices etc to be able to work out what a particular environment had at a given point in time. Your answers generated some more questions: > > How are updated RPMs in a manifest detected on the puppetmaster side? > > They are not: the puppetmaster compiles a configuration that includes > instructions (that you write) like "install version N of package M", or > "install the latest version of package M". Ok, and the puppet client determines if it has the appropriate version already in place, nothing happens- right? And the puppet client regenerates it's state, including installed packages (or at least the ones specified in the manifest), every time it pulls a configuration from the puppetmaster? The puppetmaster does nothing with the 'source' line in a package definition? Thus if we update the 'ensure' and 'source' parameters appropriately (ie make sure we match versions), the puppet client will pull the new configuration, test the version of the package installed, note that it's different, and install the rpm file specified by the source line- correct? Fully realizing that if the file specified in the source != what's in the ensure line, we'll start a package-install loop, that is, every time the client pulls a configuration down from the puppetmaster it would see the wrong version of this package is installed and re-install it. Question: will puppet handle downgrades? ie use 'rpm -f' to force the installation? Or will it only work for upgrades? Finally, we'd need to make sure the service is restarted, and possibly make sure the config files are redeployed as well, when the package is updated. In the first case, would it work to 'subscribe' the 'service' to both the package and config file definitions? (ie restart if either the package is re-installed, or the config file changes.) In the second case, would it work to subscribe the config file to the package, and the service to the config file? In both cases, the service would be restarted on either config file changes or a new version of the application RPM being installed, correct? Thanks again- Julian -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@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.
