[WIP] TRT-292: Add disruption test documentation #258
Conversation
Signed-off-by: ehila <ehila@redhat.com>
openshift-ci
bot
added
the
do-not-merge/work-in-progress
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: eggfoobar The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
|
||
| ## Summary | ||
|
|
||
| Disruption tests are a set of tests that measure an endpoints resilience or an allowed alert duration. As the `e2e tests` are run the results are matched against historical data to determine if the disruption intervals are within expectations. |
There was a problem hiding this comment.
s/endpont/endpoint's/
we are measuring disruption which is defined as the amount time an endpoint is not responding to requests (e.g., during an upgrade). The disruption testing is done independent of alerts checking.
There was a problem hiding this comment.
Please mention that the doc in this PR is specifically for documenting/explaining the part about disruption testing that relates to how disruption data is stored and later used to determine pass/fail criteria for disruption tests that are run later.
There was a problem hiding this comment.
I just saw your link on origin/pkg/synthetictests/allowedalerts/types.go and wonder if this is part of disruption testing -- I don't know the answer to this.
There was a problem hiding this comment.
Good point, the intent here was to try and cover both, from my understanding the way that the disruption and alert numbers are gathered is the same. Even the matcher is the same, the only thing that is different is the historical data set which we check against. Maybe we say this is documentation on how we determine allowed tolerations?
There was a problem hiding this comment.
I think describing both is a good idea but I think since they are quite similar, I recommend just mentioning the difference as you just explained.
|
@eggfoobar, we are discussing how best to coordinate the separate efforts for building out the disruption documentation. Also have #259 going. Want to promote one of these as a template / skeleton where we can then fill in the pieces individually. Do you have a preference for promoting incomplete doc to master or choosing one of these forks as the 'master' and merging updates into it? |
…ference easier Signed-off-by: ehila <ehila@redhat.com>
@neisw I'm okay with changing it up any way you guys see fit. If it'll make things easier I don't mind forking off of that PR so we can publish it all at the same time when we feel we've covered it well. |
|
@eggfoobar: The following test failed, say
Full PR test history. Your PR dashboard. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
@eggfoobar, if it isn't too much trouble let's do that. Feel free to supersede anything I have and / or add modify the sections. Appreciate the help on this. |
3 participants
Signed-off-by: ehila ehila@redhat.com