The param timeout for blade cmd

[Cenyol]

Because of the quality of blade, sometime it may lead to us can't interact with target system. For example, we inject network fault with 80% loss rate, and cause we can't connect the server by ssh never. May be the full load for CPU also cause the system couldn't response us at all.

So, we need guardian, and it could terminate something and recover state after we loss control. I think the param 'timeout' may be appropriate our requirement.

blade cpu --timeout 60s ...

blade network --timeout 30s ...

and so on

[Cenyol]

想要表达的大概是：
timeout参数建议提升到整个blade的级别，而不只是cpu。我之前在对网络进行测试的时候，因为把丢包设置到了80%，导致我ssh连不上，后续只能求助于运维。（估计三次握手就无法完成，因为丢包率太高了）

[wooramel]

Thank you for advice, I will think about it 👍

[aspnetdb]

'timeout' 参数不仅仅应用在一些极端的场景，还应该是每次故障实验的一个必选操作，甚至就算用户不配置，应该也有一个默认的值（比如：60s），类似sql中的limit。应对上层的演练平台异常、人为疏忽等情况。

[Cenyol]

'timeout' 参数不仅仅应用在一些极端的场景，还应该是每次故障实验的一个必选操作，甚至就算用户不配置，应该也有一个默认的值（比如：60s），类似sql中的limit。应对上层的演练平台异常、人为疏忽等情况。

You are right, so we lift it to the cmd of blade. Early it was mentioned for cpu sub cmd.

[xcaspar]

'timeout' 参数不仅仅应用在一些极端的场景，还应该是每次故障实验的一个必选操作，甚至就算用户不配置，应该也有一个默认的值（比如：60s），类似sql中的limit。应对上层的演练平台异常、人为疏忽等情况。

I agree. Can I assign this issue to you? @Cenyol

[Cenyol]

'timeout' 参数不仅仅应用在一些极端的场景，还应该是每次故障实验的一个必选操作，甚至就算用户不配置，应该也有一个默认的值（比如：60s），类似sql中的limit。应对上层的演练平台异常、人为疏忽等情况。

I agree. Can I assign this issue to you? @Cenyol

Ok, you can. ^_^

[wooramel]

implemented https://github.com/mingcheng/chaosblade.go/commit/23ad7ae1194501779cedb0c3b9417df12805247f , I will make new PR after #16 is merged.

[xcaspar]

@Cenyol @mingcheng The feature has been implemented in #16 PR which has been merged, I will release it in this week. Thank you all :-)