-
Notifications
You must be signed in to change notification settings - Fork 348
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
[FAIL] Kubevirt Virtual Machines when live migrated [It] with pre-copy should keep connectivity #3986
Comments
Ovn-kubernetes upstream issues labeled with "ci-flake" are not tracked in JIRA: let's create a jira user story under the SDN-4175 epic for each such open issue: - the assignee is kept whenever possible, otherwise bbennett is used. - the summary (title) of these jira cards will start with upstream-$GITHUB_ISSUE_ID, where $GITHUB_ISSUE_ID is the ID found in the URL of the issue itself (e.g. upstream-3986 for ovn-org/ovn-kubernetes#3986) A list of what jira stories have been created is printed to stdout, as well as a list of stories in the SDN-4175 epic whose status doesn't match the github issue they're tracking. The new "-g" ("--process-github-issues") input parameter executes this new functionality, or the script alone without any input parameters. Signed-off-by: Riccardo Ravaioli <rravaiol@redhat.com>
Ovn-kubernetes upstream issues labeled with "ci-flake" are not tracked in JIRA: let's create a jira user story under the SDN-4175 epic for each such open issue: - the assignee is kept whenever possible, otherwise bbennett is used. - the summary (title) of these jira cards will start with upstream-$GITHUB_ISSUE_ID, where $GITHUB_ISSUE_ID is the ID found in the URL of the issue itself (e.g. upstream-3986 for ovn-org/ovn-kubernetes#3986) A list of what jira stories have been created is printed to stdout, as well as a list of stories in the SDN-4175 epic whose status doesn't match the github issue they're tracking. The new "-g" ("--process-github-issues") input parameter executes this new functionality, or the script alone without any input parameters. Signed-off-by: Riccardo Ravaioli <rravaiol@redhat.com>
Ovn-kubernetes upstream issues labeled with "ci-flake" are not tracked in JIRA: let's create a jira user story under the SDN-4175 epic for each such open issue: - the assignee is kept whenever possible, otherwise bbennett is used. - the summary (title) of these jira cards will start with upstream-$GITHUB_ISSUE_ID, where $GITHUB_ISSUE_ID is the ID found in the URL of the issue itself (e.g. upstream-3986 for ovn-org/ovn-kubernetes#3986) A list of what jira stories have been created is printed to stdout, as well as a list of stories in the SDN-4175 epic whose status doesn't match the github issue they're tracking. The new "-g" ("--process-github-issues") input parameter executes this new functionality, or the script alone without any input parameters. Signed-off-by: Riccardo Ravaioli <rravaiol@redhat.com>
Ovn-kubernetes upstream issues labeled with "ci-flake" are not tracked in JIRA: let's create a jira user story under the SDN-4175 epic for each such open issue: - the assignee is kept whenever possible, otherwise bbennett is used. - the summary (title) of these jira cards will start with upstream-$GITHUB_ISSUE_ID, where $GITHUB_ISSUE_ID is the ID found in the URL of the issue itself (e.g. upstream-3986 for ovn-org/ovn-kubernetes#3986) A list of which jira stories have been created is printed to stdout, as well as a list of stories in the SDN-4175 epic whose status doesn't match the status of the github issue they're tracking. The new "-g" ("--process-github-issues") input parameter executes this new functionality, or the script alone without any input parameters. Signed-off-by: Riccardo Ravaioli <rravaiol@redhat.com>
Ovn-kubernetes upstream issues labeled with "ci-flake" are not tracked in JIRA: let's create a jira user story under the SDN-4175 epic for each such open issue: - the assignee is kept whenever possible, otherwise bbennett is used. - the summary (title) of these jira cards will start with upstream-$GITHUB_ISSUE_ID, where $GITHUB_ISSUE_ID is the ID found in the URL of the issue itself (e.g. upstream-3986 for ovn-org/ovn-kubernetes#3986) A list of which jira stories have been created is printed to stdout, as well as a list of stories in the SDN-4175 epic whose status doesn't match the status of the github issue they're tracking. The new "-g" ("--process-github-issues") input parameter executes this new functionality, or the script alone without any input parameters. Signed-off-by: Riccardo Ravaioli <rravaiol@redhat.com>
Ovn-kubernetes upstream issues labeled with "ci-flake" are not tracked in JIRA: let's create a jira user story under the SDN-4175 epic for each such open issue: - the assignee is kept whenever possible, otherwise bbennett is used. - the summary (title) of these jira cards will start with upstream-$GITHUB_ISSUE_ID, where $GITHUB_ISSUE_ID is the ID found in the URL of the issue itself (e.g. upstream-3986 for ovn-org/ovn-kubernetes#3986) A list of which jira stories have been created is printed to stdout, as well as a list of stories in the SDN-4175 epic whose status doesn't match the status of the github issue they're tracking. The new "-g" ("--process-github-issues") input parameter executes this new functionality, or the script alone without any input parameters. Signed-off-by: Riccardo Ravaioli <rravaiol@redhat.com>
@tssurya we are preparing a fix for it, it will be ready to merge today. |
Thanks @qinqon seen again here: https://github.com/ovn-org/ovn-kubernetes/actions/runs/7814875289/job/21318048354?pr=4061 |
Adding error so I can track if it's always the same.
|
I am reproducing this error at my fork running 12 jobs in parallel and a more simple tcp server so is easier to debug |
After around 25 runs show this failure with the stabilization PR
I will try to reproduce this too with the testing PR. |
I have disable interconnect and remove the policy part of the test to make it simpler also printing all the echos
Client logs
The test should not retry if first error is "connection reset by peer" since retrying will not fix anything. I am going to attach a tcpdump to the client to see if we are receving at RST packet that triggers the "connection reset by peer" at first echo. |
This should appear way less often after |
@trozet adding this link to #4237 since is the specific error related to nameserver |
Also seen in #4468 |
Seeing failures with this test still:
https://github.com/ovn-org/ovn-kubernetes/actions/runs/6646915605/job/18062050736?pr=3979
The text was updated successfully, but these errors were encountered: