Skip to content
This repository has been archived by the owner on Mar 9, 2022. It is now read-only.

vendor: kubernetes 1.19.0 rc.4 and dependencies #1551

Merged
merged 5 commits into from
Aug 10, 2020

Conversation

thaJeztah
Copy link
Member

No description provided.

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>
Comment on lines +54 to +56
golang.org/x/net ab34263943818b32f575efc978a3d24e80b04bd7
golang.org/x/sync 42b317875d0fa942474b76e1b46a6060d720ae6e
golang.org/x/sys 9dae0f8f577553e0f21298e18926efc9644c281d
golang.org/x/sys ed371f2e16b4b305ee99df548828de367527b76b
Copy link
Member Author

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

Copy link
Member

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

Comment on lines +8 to +12
// 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
Copy link
Member Author

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
Copy link
Member Author

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
Copy link
Member Author

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

Copy link
Member

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

Copy link

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

  1. 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)
  2. fixed an issue with significant performance implications
  3. 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.

Copy link
Member Author

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)

Copy link
Member Author

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

Copy link

@liggitt liggitt Aug 8, 2020

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.

Copy link

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

Copy link
Member Author

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

@thaJeztah
Copy link
Member Author

thaJeztah commented Aug 8, 2020 via email

@liggitt
Copy link

liggitt commented Aug 8, 2020

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. v4.6.0+incompatible to indicate v4.6.0 but without a go.mod file or /v4 suffix) made it really hard to understand when you were doing things correctly, and when you were doing things incorrectly and go modules were masking the issue for compatibility purposes.

@AkihiroSuda
Copy link
Member

Is this ready to be merged?

The json-patch issue doesn't seem directly related to containerd.

@thaJeztah
Copy link
Member Author

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

@AkihiroSuda AkihiroSuda added this to the v1.4 milestone Aug 10, 2020
@dims
Copy link
Member

dims commented Aug 10, 2020

+1 LGTM

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants