On Apr 29, 2013, at 11:54 AM, Atom Powers <[email protected]> wrote:
> Building on the "infrastructure as code" idea I have been thinking about how > to write tests for the infrastructure. Service monitoring seems like the > obvious answer and I am imagining something like a test suite for a > "development" version of the configuration management system that would be > used in much the same way as a programmer uses a test suite to make sure his > program works. Interesting that you bring this up. I've been working on CI work for Puppet installs, and hit an issue of integration testing of systems. There are a couple of things out there, including rspec-system (new, from Ken Barber @ puppet labs.) & serverspec. Depending on your environment, you've probably got Nagios or another service monitoring tool.. and you've got actual checks defined that can tell if a system is "right". I went looking on Friday for a decent way to trigger a full run of the checks from Nagios and return the results to Jenkins. Goal would be to not have to replicate the entire test configuration between Jenkins & Nagios… I would love to find a way to integrate Nagios into the CI workflow for the test hosts.. The API doesn't really like the concept of launch this check now, with the config that's stored in the Nagios, and provide me with the result. It may turn out that the best thing to do is build Nagios style checks for systems, and use them both for Nagios & Jenkins, but keep their configs separately. Matt brought up Jenkins: I don't think the talk is posted yet, but I just did a puppet centric CI talk @ PuppetCamp NYC last wed. In short, after doing basic static analysis testing, we moved to actually applying the puppet code on a VM that stays around for a bit, and then running integreation tests on that host. I also spoke about needing to rebuild the test hosts frequently (nightly / weekly) , to make sure that you new systems are the same as what you're testing. I'm really interested in how to make the integration tests work better for our community, but we're basically redoing the advances of the monitoring groups in a lot of way. Matthew Barr [email protected] c: (646) 727-0535 _______________________________________________ Discuss mailing list [email protected] https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss This list provided by the League of Professional System Administrators http://lopsa.org/
