Hi List, I would like to discuss with whoever is interested one topic that I suppose has general interest.
I want to implement some kind of automatic testing on the status of a node after a Puppet Run. These tests involve trivial and less trivial things things like: - A local service is running - A local port is open - A remote server on a remote port is reachable by the node - An URL replies with an expected content - Some specific function needed by the node and provided by a remote host is working (ie: ldap acces for users authentication, ntp sync...) - Whatever other check that asserts that the node is correctly working I want to do this directly in my modules, at least for the checks that are directly related to the resources provided by the module and build some defines to manage quickly things like "check the url" or "check if the remote port is accessible". The point is to have a solid testing infrastructure, early notification of any problem that might take place after a Puppet run and, at the same time have a sort of monitoring logic that might be used also by other tools, like Nagios. In order to achieve something like this there are different approaches and I would like to follow what seems most sane and, mostly, what could better fit the evolution of the Puppet ecosystem. Here a pair of examples: - APPROACH 1 - CHECK TRIGGERED BY PUPPET NODE After the Puppet run a script/command is launched and makes the necessary checks (built on the node in a dinamic way, according to the modules installed). If I'm not wrong in recent Puppet versions there's an hook that makes you run custom commands after (or before? or both?) the execution of the puppet run, so this might be the way to automate the start of the checks without too many hassles. The cons are that everything is done on the node and there's not (if not implemented specifically) a centralized management of checks runs, process logic, notifications and history. - APPROACH 2 - CHECK RUN BY AN MCOLLECTIVE CLIENT ON THE PUPPET NODE This somehow intrigues me and requires the node to have a mcollective server deamon running. The automation might be triggered remotely by the mcollective client using mcollective agents available on the Puppet node. The mcollective client should be notified of the puppetrun and might not be the same PuppetMaster, and a way to do this might be via a custom report extention that reports directly to the mcollective client. The benefit is that the monitoring can be managed via mcollective and there's a central point where data are collected and commands executed. The list of checks to be done on the client should, IMHO, remain on the Puppet client (mcollective server) itself (no need to have store configs for this) and maybe a specific agent might be done to retrieve and run from the mcollective client the list of checks to perform. Another point is how to organize and define the checks' list. Cucumber seems a nice and somehow "standard" way to define the checks logic, but could be also a plain execution of the different checks from a sort of wrapper script. The single checks could be nrpe commands and/or mcollective agents (I love the nettest one, incidentally). AFAIK there's nothing in the above examples that is particularly difficult or can't be done with existing tools, but I would like to introduce them seamlessly in my modules (using my monitoring abstraction classes). So, I wonder if someone is already doing similar checks, what's the approach they are following and what might be the evolution of Puppet under regarding these topics. Any further or related idea is welcomed, Alessandro Franceschi -- 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.
