-
Notifications
You must be signed in to change notification settings - Fork 114
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
Fix Config Daemon node selector #483
Fix Config Daemon node selector #483
Conversation
Thanks for your PR,
To skip the vendors CIs use one of:
|
/cc @SchSeba PTAL |
Pull Request Test Coverage Report for Build 5731589116
💛 - Coveralls |
/cc @zshi-redhat |
this looks good can you please add a quick unit test to cover this in the future please |
maybe the entire use of DeepDerivative is wrong here and we should use different logic to compare objects based on the type. if you swap the order then: -we would generally fail to compare resources since resourceVersion will not be ignored (since they exist in existing obj but not in obj from manifest)
now specifically for maps, looking a few lines of code down from what you referenced:
we can see it will only compare keys from v1 which after your change is the existing object |
Perhaps we should do DeepDerivative both ways(DeepDerivative(exisiting,obj) || DeepDerivative(obj, existing))? Wondering if that solves the issue or introduces new ones. |
I think Your approach of checking in a symmetrical way(in the mathematical sense) seems to be getting us close to |
FYI For Reference: 661a65b |
I've looked into this more deeply I'm in favor of removing the "get + compare" portion of the update. We do not gain anything from that. If the argument is that "update" is causing a call to the api server, then the counterargument is that the "get" isn't for free either. In addition, as evidenced by this PR, the compare part is far from trivial. |
Signed-off-by: William Zhao <[email protected]>
It was found that updating the node selector may not be applied. This test ensures that we catch any problems with the node selector being modified. Signed-off-by: William Zhao <[email protected]>
When node selectors are added then removed via "configDaemonNodeSelector" via the sriovoperatorconfigs CRD, certain combinations will not trigger an update due to the ordering of arguments into "DeepDerivative" from the reflect library. This is an example combination of setting "configDaemonNodeSelector" that would make it such that the sriov-config-daemon daemon set's nodeSelector to become out of sync with the original "DeepDerivative" argument order: Step 1) Create 3 labels in node selector: configDaemonNodeSelector = {"labelA": "", "labelB": "", "labelC": ""} config-daemon DS NodeSelector = {"labelA": "", "labelB": "", "labelC": ""} Step 2) Remove 1 label in node selector without making changes to the other labels: configDaemonNodeSelector = {"labelA": "", "labelB": ""} config-daemon DS NodeSelector = {"labelA": "", "labelB": "", "labelC": ""} (Out of Sync) "DeepDerivative" assumes that the left argument is the original (v1) and the right argument is the updated (v2). For maps it only checks if v1 > v2 in length: case reflect.Map: ... if v1.Len() > v2.Len() { return false } ... This commit just reverts changes from commit: "661a65b8e1aee6339037948732f75d06ceb91611" Use DeepDerivative to compare the kube object content Such that we react to changes to node selectors properly. Signed-off-by: William Zhao <[email protected]>
9705f0d
to
5c1b0af
Compare
Thanks for your PR,
To skip the vendors CIs use one of:
|
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.
LGTM
@adrianchiris @e0ne Please take a look when you have a chance. Thanks! |
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.
LGTM
When node selectors are added then removed via "configDaemonNodeSelector" via the sriovoperatorconfigs CRD, certain combinations will not trigger an update due to the ordering of arguments into "DeepDerivative" from the reflect library.
This is an example combination of setting "configDaemonNodeSelector" that would make it such that the sriov-config-daemon daemon set's nodeSelector to become out of sync with the original "DeepDerivative" argument order:
"DeepDerivative" assumes that the left argument is the original (v1) and the right argument is the updated (v2). For maps it only checks if v1 > v2 in length:
This commit just reverts changes from commit:
"661a65b8e1aee6339037948732f75d06ceb91611"
Use DeepDerivative to compare the kube object content
Such that we react to changes to node selectors properly.