On 14 August 2014 07:31, Menno Smits menno.sm...@canonical.com wrote:
I like the idea being able to trigger failures using the juju command line.
I'm undecided about how the need to fail should be stored. An obvious
location would be in a new collection managed by state, or even as a field
on
Ah, and one more thing: when developing the chaos-injection mechanism
in the mgo/txn package, I also added both a chance parameter for
either killing or slowing down a given breakpoint. It sounds like it
would be useful for juju's mechanism too. If you kill every time, it's
hard to tell whether
Not much to add except to say I really like this work and I think it is
going to really help us make Juju much better when encountering failures. I
also like the idea of providing easy access to triggering failures through
CLI commands.
On Wed, Aug 13, 2014 at 10:29 AM, Gustavo Niemeyer
I like the idea being able to trigger failures using the juju command line.
I'm undecided about how the need to fail should be stored. An obvious
location would be in a new collection managed by state, or even as a field
on existing state objects and documents. The downside of this approach is
I like the idea of being able to trigger failures stochastically. I'll
integrate this into whatever we settle on for Juju's failure injection.
On 14 August 2014 02:29, Gustavo Niemeyer gustavo.nieme...@canonical.com
wrote:
Ah, and one more thing: when developing the chaos-injection mechanism
