Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

kube-monkey should respect the termination grace period defined in the pod spec #118

Closed
asobti opened this issue Nov 17, 2018 · 3 comments
Closed

Comments

@asobti
Copy link
Owner

asobti commented Nov 17, 2018

If a TerminationGracePeriod is defined in the pod spec and it is larger than the configured grace period, the TerminationGracePeriod value should be used

asobti pushed a commit that referenced this issue Nov 17, 2018
asobti pushed a commit that referenced this issue Nov 20, 2018
asobti pushed a commit that referenced this issue Nov 20, 2018
asobti pushed a commit that referenced this issue Nov 20, 2018
asobti pushed a commit that referenced this issue Nov 20, 2018
@jroper
Copy link

jroper commented Dec 19, 2019

Doesn't this defeat the purpose of chaos testing? Failures don't happen gracefully, it's easy to make sure things work when you terminate things gracefully, and things get terminated gracefully all the time (eg during rolling upgrades) so there's no point having an additional service like this testing that. The hard thing is to make things work when things don't terminate gracefully, ie, when they fail, that's why we have chaos testing. I would say that honouring a pods graceful termination period is not failure testing, and undermines all confidence that this tool provides. Failure testing requires a graceful termination period of zero seconds.

@asobti
Copy link
Owner Author

asobti commented Dec 19, 2019

@jroper Agreed with everything you say. This is tracked by #134

@asobti
Copy link
Owner Author

asobti commented Dec 19, 2019

@jroper Fixed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants