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

add new flowHelper method: getFlowHistoryByAction #2791

Closed
wants to merge 1 commit into from

Conversation

andriidovhan
Copy link
Contributor

No description provided.

@andriidovhan andriidovhan force-pushed the test/add-helper-getFlowHistoryByAction branch from 2c8e0c1 to 12ec9d8 Compare September 12, 2019 13:11
@andriidovhan andriidovhan force-pushed the test/add-helper-getFlowHistoryByAction branch from 12ec9d8 to 2560567 Compare September 16, 2019 07:31
@andriidovhan andriidovhan force-pushed the test/add-helper-getFlowHistoryByAction branch from 2560567 to 3f1dee7 Compare September 19, 2019 12:12
@andriidovhan andriidovhan force-pushed the test/add-helper-getFlowHistoryByAction branch from 3f1dee7 to 0b0a690 Compare September 20, 2019 10:46
Copy link
Collaborator

@rtretyak rtretyak left a 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


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),
Copy link
Collaborator

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

Copy link
Contributor Author

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

Copy link
Collaborator

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?

Copy link
Contributor Author

@andriidovhan andriidovhan left a 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),
Copy link
Contributor Author

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) {
Copy link
Collaborator

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
Copy link
Collaborator

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
Copy link
Collaborator

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
Copy link
Collaborator

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),
Copy link
Collaborator

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)
Copy link
Collaborator

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.

@andriidovhan
Copy link
Contributor Author

I am going to rework it at all
So I will create a new pr

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

Successfully merging this pull request may close these issues.

None yet

2 participants