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
capture: Calculated captured state from nmstatectl #998
capture: Calculated captured state from nmstatectl #998
Conversation
6ddb538
to
a471fd3
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.
The fix looks good.
@qinqon Interesting that we didn't hit this issue in u/s CI, do you think it's worth adding a test scenario that reproduced this in a followup?
/lgtm
/approve
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: rhrazdil The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/cherry-pick release-0.64 |
@qinqon: once the present PR merges, I will cherry-pick it on top of release-0.64 in a new PR and assign it to you. In response to this:
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. |
Calculating the captured state with the NNS is problematic since there are some latencies between nmstatectl set and NNS being updated, so it could happend that next NNCP is calculated with inaccurate network configuration. This change read the currentState from nmstatectl to get accurate data. Signed-off-by: Quique Llorente <ellorent@redhat.com>
a471fd3
to
ef4c068
Compare
/lgtm |
/retest |
Since it's a race it depends how much time happends between one NNCP and the next, also what do we do on the next NNCP, if both NNCP use capture and one capture is using the previous as input then we can end with the issue at hand. |
/retest |
Thanks, understood. |
/cherry-pick release-0.64 |
@qinqon: once the present PR merges, I will cherry-pick it on top of release-0.64 in a new PR and assign it to you. In response to this:
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. |
/retest It suffers from DNS resolve ping, let's retry
|
/retest |
This time, the go build failed again |
ARM build sometimes fail... |
@qinqon: #998 failed to apply on top of branch "release-0.64":
In response to this:
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. |
Calculating the captured state with the NNS is problematic since there are some latencies between nmstatectl set and NNS being updated, so it could happend that next NNCP is calculated with inaccurate network configuration. This change read the currentState from nmstatectl to get accurate data. Cherry picked from (nmstate#998) Signed-off-by: Quique Llorente <ellorent@redhat.com>
Calculating the captured state with the NNS is problematic since there are some latencies between nmstatectl set and NNS being updated, so it could happend that next NNCP is calculated with inaccurate network configuration. This change read the currentState from nmstatectl to get accurate data. Cherry picked from (#998) Signed-off-by: Quique Llorente <ellorent@redhat.com>
Calculating the captured state with the NNS is problematic since there are some latencies between nmstatectl set and NNS being updated, so it could happend that next NNCP is calculated with inaccurate network configuration. This change read the currentState from nmstatectl to get accurate data. Signed-off-by: Quique Llorente <ellorent@redhat.com>
Is this a BUG FIX or a FEATURE ?:
/kind bug
What this PR does / why we need it:
Calculating the captured state with the NNS is problematic since there
are some latencies between nmstatectl set and NNS being updated, so it
could happend that next NNCP is calculated with inaccurate network
configuration. This change read the currentState from nmstatectl to get
accurate data.
Special notes for your reviewer:
Fix bz https://bugzilla.redhat.com/show_bug.cgi?id=2057613
Release note: