fault-injection

The library controller-runtime requires setting a logger (by log.SetLogger()) at the first 30s when the application starts, or it would use the default NullLogSink. We should also call it in testing codes.

When we test with ginkgo, ginkgo provides a helpful GinkgoWriter, which hides the output as default, only prints it when the test failed. We'd better use it to keep our testing output

Issue Description

Question

Describe what happened (or what feature you want)

Trying to evaluate ChaosBlade as an option for resiliency testing. But I'm not sure if this is a feature request or a question. Actually, two questions:

• Does ChaosBlade support Azure, or can it be extended to support Azure?
• Can ChaosBlade inject failures into a Platform as a Service (Pa

We can add an upgrade/downgrade command for litmusctl binary, it can look at the matrix of versions in a file and upgrade/downgrade according to the user's choice.

example

• litmusctl upgrade v0.5.0
• litmusctl downgrade v0.4.0

One problem with faulting programs under KRF is that KRF might decide to inject a fault during the dynamic link/load phase, aborting ld-linux.so instead of the actual target image. This usually isn't helpful, since it doesn't indicate any mistakes in the target itself.

It should be possible to check the loaded program's name via the current task, probably via comm. We should use that (or