On 4/22/15 11:28 AM, Torben Knerr wrote:
A more concrete example: say I have a cookbook for setting upMy intuition is that the way that you're thinking about that violates promise theory a bit. All of your tests should be "from the inside". The VM that your webapp is being deployed on should really only test the world from its perspective. It should test that its listening on its http port and that basic API calls can succeed and that it can make calls to a database. Trying to think about it begin responsible for testing its own VIP violates promise theory since now its responsible for distant infrastructure and it doesn't have the information that it may need (it could be failing to register correctly in the VIP but another server in the cluster could be serving content so the VIP is up). Its better to add tests to the loadbalancer "from the inside" so that the load balancer checks itself and validates that all its exepected clients are listed as avaiable and health checks are passing and the loadbalancer should be checking its own VIP.
JenkinsCI with Slaves on multiple nodes, with nginx in front, etc..
I'd like to have a test suite that:
- sets up the multi-node scenario
- then verifies that the front page is served...
- ...and that you can create a basic job that is executed on a slave
- ...and so on (some basic acceptance level smoke tests)
That's what I'm up to... did it get clearer?
Then what we need is a multi-node test-kitchen which used something like chef-provisioning to spin up all of these VMs and fire off the serverspec runs on all of them, and then report back. For deployed infrastructure then audit mode could be running serverspec tests (and ideally hook busser up to audit mode so you could audit with bats tests and whatever) and you'd be getting reports back on every chef-client converge or audit mode run.
Archive powered by MHonArc 2.6.16.