-
Notifications
You must be signed in to change notification settings - Fork 121
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
Percentage per pod, kill times and weekends #47
Conversation
@klautcomputing I like 1. very much and also 2. makes sense. I'm off for a week but I'll get back to you then. |
Thanks for the feedback. I hope I will find time this week to move this forward a little. |
@linki So I guess I am done with this :) There is one fundamental assumption that might not be obvious at first: I will update the readme once you give me a 👍 about merging this. I will deploy it in my cluster and play with it. And might come back with code changes. |
@linki I needed to |
I ran it in my cluster today and played with it for a bit and noticed and fixed a couple of things. Most importantly before this commit pods that didn't specified |
@linki can I ping you on this :) |
@linki and @klautcomputing - I just started thinking about adding the "weekends" feature and discovered this PR. But because of the huge number of changed source files, I cannot determine what exactly is being proposed. Please have a look at my suggestion in this Feature "Issue". |
@twildeboer It is about 3 files that you need to look at: |
663d155
to
ddd0564
Compare
Hi @klautcomputing @twildeboer, I cleaned up the PR so it's easier to review:
Hope this was okay, @klautcomputing. |
ddd0564
to
55340b5
Compare
I am not sure how to proceed with this PR because I feel we didn't reach a real conclusion with our discussion. Things that are unclear for me right now:
If I don't hear back from you, @linki and @twildeboer I will just make best effort and judgement changes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the delay in reviewing.
IMO, the percentage feature should be a separate pull request from the "suspend chaos" feature, since they are unrelated.
Also, IMO, the "suspend chaos" feature should have a notion of timezone since I think most people would want to express these configurations in terms of their local time, regardless of the timezone of the actual pod (which would most likely be UTC).
Please have a look at my take on the implementation.
I am closing this because I don't feel I got any concrete input and I don't have the time to actually work on it anymore. |
This is still very pseudocode-y mainly for the reason that I wanted to get some early feedback on this before I touch it up. In #34 I started some work which I think will get us nowhere, therefore this new PR with a different approach and two new features for chaoskube:
I would like it if every resource could determine on its own how often it would like to get killed:
Therefore, I propose we add the label:
chaoskube.schedule
with values like1/hour
3/week
2/month
that let us determine how often a victim should get killed.I want to tackle Create more chaos during business hours #35 and thus I added the flags:
excludeWeekends
,runFrom
andrunUntil
that let you determine whenchaoskube
should be active.Let me know what you think, browse through my code and if you like the approach + the in some parts pseudo-y code I will touch it up and test it.
@linki (just because I always loose my github notifications)