-
Notifications
You must be signed in to change notification settings - Fork 349
fix: Incorrect comparison logic when comparing lists #1060
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
base: master
Are you sure you want to change the base?
fix: Incorrect comparison logic when comparing lists #1060
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
ranakan19
left a comment
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.
Do we have any data on the impact of sorting before comparison here? Maybe we have any performance tests that can be run to measure the impact?
My concern is that sorting generally has a higher time complexity (O(nlogn) in the best cases). Unless size is bound or is not performance-sensitive, I'm cautious of sorting beforehand. So looking for more context about this decision
|
Question, not an objection: Can we assume that list order is insignificant in all those cases? For instance, Thinking about EnvVars that override one another, or VolumeMounts that either override, or mount inside one another's mount path. If I, as an admin, get them in a wrong order and then fix it, the operator may refuse to update it therefore not letting me fix it. |
From what I understand so far, the deployment generated by the operator doesn’t support duplicate env var names or overlapping volume mount paths. Because of that, the order of these lists doesn’t seem to carry semantic meaning in this context. Sorting them helps avoid false positives caused by non-deterministic ordering from etcd, without hiding any meaningful changes. |
Thought of this, these lists(containers, env, volumes, tolerations) are very small and this code runs only during reconciliation, not in a hot path. So I think In this case, sorting is more efficient than the alternative(unnecessary updates and API calls during reconciliation caused by false positives due to non-deterministic list ordering from etcd). |
|
/retest |
Signed-off-by: Atif Ali <atali@redhat.com>
Signed-off-by: Atif Ali <atali@redhat.com>
Signed-off-by: Atif Ali <atali@redhat.com>
Signed-off-by: Atif Ali <atali@redhat.com>
Signed-off-by: Atif Ali <atali@redhat.com>
Signed-off-by: Atif Ali <atali@redhat.com>
Signed-off-by: Atif Ali <atali@redhat.com>
a9a8edc to
931ca4c
Compare
|
I have tried to test and |
|
@aali309: The following tests failed, say
Full PR test history. Your PR dashboard. DetailsInstructions 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-sigs/prow repository. I understand the commands that are listed here. |
|
What type of PR is this?
See: GITOPS-8018
/kind bug
What does this PR do / why we need it:
This change sorts deployment lists before comparison to prevent false updates when
etcd returns containers, volumes, or tolerations in different order.
Have you updated the necessary documentation?
Which issue(s) this PR fixes:
Fixes #? GITOPS-8018
Test acceptance criteria:
How to test changes / Special notes to the reviewer: