On Oct 19, 10:52 pm, Nicolas Szalay <nsza...@qualigaz.com> wrote: > ----- "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 ?
Yes, but as far as I've understood, puppet-cucumber is run on the Puppet Master and check resources managed by Puppet. I'd like also to make checks that might not be directly related to Puppet resources (but might be broken by a wrong config pushed via Puppet). > > | 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 In fact, and that's a reason why I don't prefer this approach, because you should build your own reporting stuff. > > | - 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. +1 > > | 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. I'll let you know if I make up something interesting :-) Al -- 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.
