-
Notifications
You must be signed in to change notification settings - Fork 349
vendor: kubernetes 1.19.0 rc.4 and dependencies #1551
vendor: kubernetes 1.19.0 rc.4 and dependencies #1551
Conversation
full diff: json-iterator/go@v1.1.9...v1.1.10 - Fix 459 map keys of custom types should serialize using MarshalText when available - Fix potential panic in (*stringAny).ToInt64 and (*stringAny).ToUint64 (see 450) - Fix 449 do NOT marshal the field whose name start with underscore - Reuse stream buffer and remove flush in (*Stream).WriteMore(see 441 440) - Fix 421 simplify the error string returned by the decoder when it meets error unmarshaling anonymous structs - Fix 389 411 do NOT marshal the json.RawMessage type field whose real type is integer/float as "null" with ValidateJsonRawMessage option enabled - Fix 326 do Not marshal private field after calling extra.SetNamingStrategy() to register naming strategy extension Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
full diff: golang/net@f3200d1...ab34263 Worth mentioning that there's a comment updated in golang.org/x/net/websocket: This package currently lacks some features found in alternative and more actively maintained WebSocket packages: https://godoc.org/github.com/gorilla/websocket https://godoc.org/nhooyr.io/websocket It's used in k8s.io/apiserver/pkg/util/wsstream/stream.go, so perhaps that should be reviewed if the alternatives are better for how it's used. Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
full diff: golang/sys@9dae0f8...ed371f2 Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
full diff: golang/crypto@bac4c82...75b2880 Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
golang.org/x/net ab34263943818b32f575efc978a3d24e80b04bd7 | ||
golang.org/x/sync 42b317875d0fa942474b76e1b46a6060d720ae6e | ||
golang.org/x/sys 9dae0f8f577553e0f21298e18926efc9644c281d | ||
golang.org/x/sys ed371f2e16b4b305ee99df548828de367527b76b |
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.
Note that these are in the "containerd dependencies" section. Wondering if they should stay in that section (and thus need to be updated there first), or if we need some "generic" section, as these are used in various places, not just containerd
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.
we'll be merging the cri repo soon into containerd .. agree once something has two major dependencies it's time to move it to a more generic list
// This package currently lacks some features found in alternative | ||
// and more actively maintained WebSocket packages: | ||
// | ||
// https://godoc.org/github.com/gorilla/websocket | ||
// | ||
// https://godoc.org/nhooyr.io/websocket |
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 noticed this change in the comment, which relates to golang/go#18152
It's used in k8s.io/apiserver/pkg/util/wsstream/stream.go, so perhaps that should be reviewed if the alternatives are better for how it's used.
k8s.io/kube-openapi v0.0.0-20200427153329-656914f816f9 | ||
sigs.k8s.io/structured-merge-diff/v3 v3.0.0 | ||
sigs.k8s.io/structured-merge-diff/v3 v3.0.1-0.20200706213357-43c19bbb7fba |
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 skipped the update to sigs.k8s.io/structured-merge-diff, as it would bring in a non-released version, and didn't bring changes in the vendored files
|
||
require ( | ||
github.com/davecgh/go-spew v1.1.1 | ||
github.com/docker/spdystream v0.0.0-20160310174837-449fdfce4d96 | ||
github.com/elazarl/goproxy v0.0.0-20180725130230-947c36da3153 | ||
github.com/evanphx/json-patch v4.2.0+incompatible | ||
github.com/evanphx/json-patch v0.0.0-20190815234213-e83c0a1c26c8 |
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.
Perhaps something for @dims - I noticed kubernetes switched to this version to get a fix/feature in. This commit is somewhere between v4.5.0 and v4.6.0:
evanphx/json-patch@e83c0a1...v4.6.0
There's also a v4.7.0 release, that fixes some bugs:
evanphx/json-patch@v4.6.0...v4.7.0
So, perhaps k/k can update to that version to get back on a released version of the dependency. I can try opening a PR to k/k (not sure if there's special magic needed to update dependencies there 😅), or perhaps someone else has time to do so
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.
@thaJeztah we are a bit sensitive to json-patch historically i think. Will run it by @liggitt. It is ok for containerd to switch first. We will just pick it up when we rev to containerd 1.4.0
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.
between v4.5.0 and v4.6.0, json-patch did the following things in this order:
evanphx/json-patch@v4.5.0...v4.6.0
- added a go.mod file which made semver revisions unaddressable until they renamed to
github.com/evanphx/json-patch/v5
(done in v5.0.0) - fixed an issue with significant performance implications
- changed behavior to be RFC-compliant, but which is potentially breaking for API consumers
We are not yet comfortable picking up the behavior-breaking changes (especially not to backport to a patch release, see discussion in kubernetes/kubernetes#91622 (comment)), but did want the bugfix.
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.
It is ok for containerd to switch first. We will just pick it up when we rev to containerd 1.4.0
Heh, well, containerd (nor containerd/cri) currently vendor it / depend on it (it was actually a facepalm moment that I looked at the versions, then realised it's not used here) 😂
changed behavior to be RFC-compliant, but which is potentially breaking for API consumers
We are not yet comfortable picking up the behavior-breaking changes (especially not to backport to a patch release, see discussion in kubernetes/kubernetes#91622 (comment), but did want the bugfix.
Ahm, gotcha, I thought it was updated to get the fix, and this commit was "latest" at that point, and it wasn't updated after.
We are not yet comfortable picking up the behavior-breaking changes
That makes perfect sense. So looking at the diff, it looks like evanphx/json-patch@a5df74a is the offending commit. This actually sounds like the exact scenario for which go modules were designed. Given that this is a (potentially) breaking change, that warrants a major version bump, so it could (/should) be considered a mistake that it was merged in a minor release.
Perhaps we should suggest a revert of that commit, and a v4.8.0 tag to be created. Given that they have a v5.x version now, this gives consumers of the package the opportunity to opt-in to the new behavior when ready, and others to stay on v4.x until they're ready for the change.
I guess Kubernetes is the most prominent consumer of that package (https://grep.app/search?q=github.com/evanphx/json-patch), and still is on v4 (kubernetes-sigs/kind looks to have made the switch to v5, so should not be affected by a revert https://grep.app/search?q=github.com/evanphx/json-patch/v5)
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 went ahead and opened a pull request for consideration; evanphx/json-patch#111
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 tagged v4.8.0 now has the performance fixes with no compatibility breaks compared to 4.6.0. It does still contain a go.mod file requiring it to be addressed as v0.0.0-20200808040245-162e5629780b
in go.mod files
Opened evanphx/json-patch#113 to drop the go.mod file in the 4.x stream for tidyness, though it would only affect usage by go module-based consumers.
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.
btw, json-patch v4.9.0 was just released that once again allows addressing as v4.9.0+incompatible
via go modules
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.
Perfect! Thanks for the update
Ah, yes, I just was fiddling with that, trying to update the dependency in kubernetes; looks like go1.13+ no longer allows that, and refuses to get the dependency.
tbh these breaking changes in Golang modules are kinda infuriating (imo even should warrant a major version bump of Golang itself)
… On 8 Aug 2020, at 16:19, Jordan Liggitt ***@***.***> wrote:
@liggitt commented on this pull request.
In vendor/k8s.io/apimachinery/go.mod:
>
require (
github.com/davecgh/go-spew v1.1.1
github.com/docker/spdystream v0.0.0-20160310174837-449fdfce4d96
github.com/elazarl/goproxy v0.0.0-20180725130230-947c36da3153
- github.com/evanphx/json-patch v4.2.0+incompatible
+ github.com/evanphx/json-patch v0.0.0-20190815234213-e83c0a1c26c8
The tagged v4.8.0 is functionally correct with no breaking changes, but still contains a go.mod file requiring it to be addressed as v0.0.0-20200808040245-162e5629780b in go.mod files
Opened evanphx/json-patch#113 to drop the go.mod file in the 4.x stream for tidyness, though it would only affect usage by go module-based consumers.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
I agree it is difficult... we accidentally tagged a version of client-go with a go.mod file as v12.0.0 not realizing that was an invalid tag. It was officially documented as disallowed, but was not enforced until go1.13. The backwards compatibility scenarios go modules added (e.g. |
Is this ready to be merged? The json-patch issue doesn't seem directly related to containerd. |
Correct; I just noticed it in the diff, but not related to this repository (or this PR), so this should be ready for review |
+1 LGTM |
No description provided.