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
add new flowHelper method: getFlowHistoryByAction #2791
Conversation
...ctional-tests/src/main/groovy/org/openkilda/functionaltests/helpers/FlowHistoryAction.groovy
Show resolved
Hide resolved
...src/functional-tests/src/main/groovy/org/openkilda/functionaltests/helpers/FlowHelper.groovy
Outdated
Show resolved
Hide resolved
2c8e0c1
to
12ec9d8
Compare
12ec9d8
to
2560567
Compare
...src/functional-tests/src/main/groovy/org/openkilda/functionaltests/helpers/FlowHelper.groovy
Show resolved
Hide resolved
...ctional-tests/src/main/groovy/org/openkilda/functionaltests/helpers/FlowHistoryAction.groovy
Outdated
Show resolved
Hide resolved
2560567
to
3f1dee7
Compare
3f1dee7
to
0b0a690
Compare
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.
It would be also great if you would try to asses performance degradation related to switching to 'history' approach compared to 'status' approach
...ctional-tests/src/main/groovy/org/openkilda/functionaltests/helpers/FlowHistoryAction.groovy
Show resolved
Hide resolved
|
||
REROUTE_SUCCESS(FlowHistoryAction.FLOW_REROUTING, FlowHistoryAction.SET_THE_FLOW_STATUS_TO_UP), | ||
REROUTE_FAIL(FlowHistoryAction.FLOW_REROUTING, FlowHistoryAction.SET_THE_FLOW_STATUS_TO_DOWN), | ||
REROUTE_FAIL_PROTECTED_PATH(FlowHistoryAction.FLOW_REROUTING, FlowHistoryAction.FLOW_WAS_VALIDATED_SUCCESSFULLY), |
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.
I am a bit confused how FLOW_REROUTING + FLOW_WAS_VALIDATED_SUCCESSFULLY is related to protected paths
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.
I just copied it from flowHistory output after flowState was changed to DEGRADED
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.
Why do you call it like that? It clearly means that flow is validated after reroute
and I would agree with that, but the 'reroute fail for protected path' is just a special case of your test. The flow is validated, and you expect a degraded status in your exact special test, that's fine. But you cannot globally assume that 'rerouting + successfull validation' means 'reroute for protected path failed', that breaks laws of logic. Crocodiles are green, crocodiles are dangerous. Grass is green -> grass is dangerous?
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.
It would be also great if you would try to asses performance degradation related to switching to 'history' approach compared to 'status' approach
it will add around half a second to each test
verifyFlowstate(ms) | getFlowStatus(ms) | |
---|---|---|
1 | 4564 | 3815 |
2 | 3946 | 4312 |
3 | 4501 | 3774 |
4 | 3914 | 3788 |
5 | 3871 | 4288 |
6 | 3314 | 4304 |
7 | 3859 | 3825 |
8 | 3840 | 3752 |
9 | 4517 | 3817 |
10 | 4424 | 3275 |
11 | 4485 | 3755 |
average: | 4112,272727 | 3882,272727 |
|
||
REROUTE_SUCCESS(FlowHistoryAction.FLOW_REROUTING, FlowHistoryAction.SET_THE_FLOW_STATUS_TO_UP), | ||
REROUTE_FAIL(FlowHistoryAction.FLOW_REROUTING, FlowHistoryAction.SET_THE_FLOW_STATUS_TO_DOWN), | ||
REROUTE_FAIL_PROTECTED_PATH(FlowHistoryAction.FLOW_REROUTING, FlowHistoryAction.FLOW_WAS_VALIDATED_SUCCESSFULLY), |
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.
I just copied it from flowHistory output after flowState was changed to DEGRADED
* @param event sequence of flow history actions | ||
* @param state expected flow state | ||
*/ | ||
void verifyFlowState(String flowId, Long timeFrom, FlowHistoryEvent event, state) { |
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.
Please add a strict type for state
* Check that flow state is changed correctly after corresponding flow history action. | ||
* | ||
* @param flowId | ||
* @param timeFrom history will requested from this timestamp |
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.
will be
def flowHistory = northbound.getFlowHistory(flowId, timeFrom, timeTo).findAll { | ||
it.action == event.initAction.toString() | ||
} | ||
assert flowHistory.size() == 1 |
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.
are you sure that you want to limit your method with this condition? What if there were more actions on the flow? I'm not insisting, but for me it kind of limits where it can be used or forces to use the 'from' timestamp. that's fine I guess, but requires a lot of 'timestamp' vars for long tests
* @param state expected flow state | ||
*/ | ||
void verifyFlowState(String flowId, Long timeFrom, FlowHistoryEvent event, state) { | ||
def timeTo = timeFrom ? System.currentTimeSeconds() : null |
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.
well, this is kind of tricky. timeTo based on timeFrom, why would you do this? Very strange and not intuitive approach
|
||
REROUTE_SUCCESS(FlowHistoryAction.FLOW_REROUTING, FlowHistoryAction.SET_THE_FLOW_STATUS_TO_UP), | ||
REROUTE_FAIL(FlowHistoryAction.FLOW_REROUTING, FlowHistoryAction.SET_THE_FLOW_STATUS_TO_DOWN), | ||
REROUTE_FAIL_PROTECTED_PATH(FlowHistoryAction.FLOW_REROUTING, FlowHistoryAction.FLOW_WAS_VALIDATED_SUCCESSFULLY), |
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.
Why do you call it like that? It clearly means that flow is validated after reroute
and I would agree with that, but the 'reroute fail for protected path' is just a special case of your test. The flow is validated, and you expect a degraded status in your exact special test, that's fine. But you cannot globally assume that 'rerouting + successfull validation' means 'reroute for protected path failed', that breaks laws of logic. Crocodiles are green, crocodiles are dangerous. Grass is green -> grass is dangerous?
@@ -893,17 +893,22 @@ class ProtectedPathSpec extends HealthCheckSpecification { | |||
antiflap.portDown(protectedIsls[0].dstSwitch.dpId, protectedIsls[0].dstPort) | |||
|
|||
then: "Flow state is changed to DEGRADED" | |||
Wrappers.wait(WAIT_OFFSET) { assert northbound.getFlowStatus(flow.id).status == FlowState.DEGRADED } | |||
Wrappers.wait(WAIT_OFFSET) { | |||
flowHelper.verifyFlowState(flow.id, FlowHistoryEvent.REROUTE_FAIL_PROTECTED_PATH, FlowState.DEGRADED) |
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.
This is literally false expression. You are not verifying that the reroute failed for protected path, you are just checking that a successful validation happened.
I am going to rework it at all |
No description provided.