-
Notifications
You must be signed in to change notification settings - Fork 38.7k
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 merging with conflict by upgrade mergo version to v0.3.12 #107837
Fix merging with conflict by upgrade mergo version to v0.3.12 #107837
Conversation
b26ea0a
to
84a9694
Compare
/triage accepted |
84a9694
to
8ef2b00
Compare
8ef2b00
to
d4487f4
Compare
d4487f4
to
038152e
Compare
// insecure-skip-tls-verify: true | ||
// server: http://a-different-cow.org:8080 |
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.
This unit test is explicitly checking what the resulting configuration is when we merge two files. This test change demonstrates the library update is flipping merge behavior and breaking compatibility with existing kubeconfig merge order.
Revert the changes to this file. If the mergo library changed behavior, we'll need to adjust how we're calling it to preserve the existing behavior of kubeconfig merging.
Looking at git history, that unit test has been asserting that merge behavior since kubeconfig files were introduced in https://github.com/kubernetes/kubernetes/pull/3316/files#diff-c1a584208d3dad4c9c57651c1f67dae98842323f5753a60460979792642666ccR71-R112 in 2015, prior to Kubernetes v1.0. At the time, that was using a 0.1.4-era version of mergo. The current behavior of merging two kubeconfig files is what we need to preserve. If we want to update the mergo library, that's ok, but we have to maintain compatibility with our existing merge behavior. |
/hold |
/close due to inactivity. an update that preserves existing kubeconfig / client-go behavior would be fine |
@liggitt: Closed this PR. 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. |
/reopen @liggitt I am very sorry for the delay. An update that preserves existing behavior has been submitted. PTAL. Thanks. |
@jlsong01: Reopened this PR. 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. |
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: jlsong01 The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
038152e
to
75a72e4
Compare
New changes are detected. LGTM label has been removed. |
/retest |
1 similar comment
/retest |
@@ -72,6 +72,7 @@ func deepMap(dst, src reflect.Value, visited map[uintptr]*visit, depth int, conf | |||
case reflect.Struct: | |||
srcMap := src.Interface().(map[string]interface{}) | |||
for key := range srcMap { | |||
config.overwriteWithEmptyValue = true |
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.
this really seems like a bug in mergo... this is mutating the merge configuration options passed in and I don't see it getting restored to it's configured value
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.
yup, reported at darccio/mergo#187
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.
@liggitt So, how about this PR? shall we upgrade the mergo version preserving existing behavior now? Or, wait for mergo project fixing it then upgrade mergo?
as #107499 reports: "client-go behavior changes depending on version of github.com/imdario/mergo used. Kubernetes pins to v0.3.5. Many other projects in the ecosystem, including Kubernetes projects like sigs.k8s.io/controller-runtime, use newer versions like 0.3.12.
If a consumer of client-go is not careful, they will very likely automatically use mergo. This will subtly give different behavior than client-go declares. Users of client-go must therefor use a replace for mergo (if they care about this issue), which also implies all downstream consumers must do the same and go install will not work."
maybe it's better to pick up this PR in order to unify the mergo version.
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.
I think I'd rather see us drop mergo and implement our own merging of these fields given the repeated behavior reversals and long-standing bugs. Our usage seems very limited
/close I don't see us picking up a version of mergo with the bug noted in #107837 (comment) I think the best resolution of #107499, given the number of times this dependency has reversed behavior on minor bumps, would be to eliminate use of the dependency and write our own merge of our narrow use |
@liggitt: Closed this PR. 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. |
What type of PR is this?
/kind bug
What this PR does / why we need it:
client-go pins to mergo v0.3.5, seems v0.3.5 has some bug, which can not handle merge with confilct correctly.
Since unit test
Example_mergingSomeWithConflict
uses mergo v0.3.5, the merge process is wrong and the corresponing ut expection is wrong as well.We need upgrade mergo version into the latest v0.3.12 and modify the
Example_mergingSomeWithConflict
expection accordingly.Which issue(s) this PR fixes:
Fixes #107499
Special notes for your reviewer:
According to my test, the mergo bug has been fixed since v0.3.8, but have not found the releated issue report.
Does this PR introduce a user-facing change?
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.: