----- "Al @ Lab42" <lab42...@gmail.com> a écrit : | Hi List,
Hi, | 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. Do you know about puppet-cucumber ? | 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 This is an easy approach but how will you push information back to you ? I have not checked but I don't think that the result of post run hooks are included into reports | - APPROACH 2 - CHECK RUN BY AN MCOLLECTIVE CLIENT ON THE PUPPET NODE I would use that one, combined with nagios through the mc nrpe agent probably or something like a hudson instance to do a permanent check about this. | 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. Not doing it but definitely interested. Nico. -- 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.
