Remove int support from json patches

[ash2k]

What this PR does / why we need it:
JSON only contains int64 and float64 types for numbers so int is not needed.

Special notes for your reviewer:
This is a follow up for #62981.

Release note:

NONE

/sig api-machinery
/kind cleanup
/cc liggitt sttts

[ash2k]

/retest

[ash2k]

/retest

[lavalamp]

/assign @mbohlool

JSON doesn't reliably transport numbers bigger than 54 bits...

[ash2k]

/retest

[lavalamp]

Why would we remove int? int64 is the thing that's not reliably transmitted by JSON?

[mbohlool]

JSON only contains int64 and float64 types for numbers

JSON number does not have type actually. It is safer to use int32 vs int64 as most parsers support up to 53 bits. Anyhow I don't see any reasoning in the referenced issue why we should remove int.

/hold

[ash2k]

Originally JSON parser produces only float64 for numbers when marshalled into interface{}. JSON parser we use only ever produces either int64 or float64 for numbers. int is just not needed.

[ash2k]

@mbohlool there is a misunderstanding. I'm talking about parsed JSON (map[string]interface{} etc), not JSON itself. I know that JSON does not have integers, only floats.

[ash2k]

Anyhow I don't see any reasoning in the referenced issue why we should remove int.

What is the reasoning to keep it? Why have int but not, say, int32 and/or int16?

[mbohlool]

/unhold

[ash2k]

@mbohlool /hold cancel please :)
@liggitt PTAL

[mbohlool]

/hold cancel

[ash2k]

/retest

[sttts]

Sgtm. Can you blame who owns the json patch code?

[sttts]

JSON number does not have type actually. It is safer to use int32 vs int64 as most parsers support up to 53 bits. Anyhow I don't see any reasoning in the referenced issue why we should remove int.

@mbohlool in all our JSON data structure code we have an invariant on the valid types (which do not include int). We have code paths which even panic (intentionally) if they happen to hit an unknown type. So this PR is correct and desired from this point of view.

[ash2k]

@sttts
Code in k8s.io/apimachinery/pkg/util/jsonmergepatch/patch.go was introduced in #40666

k8s.io/apimachinery/pkg/util/mergepatch/util.go was refactored in #40942, originally introduced in #16980

k8s.io/apimachinery/pkg/util/strategicpatch/patch.go was also introduced in #16980

FYI @jackg @mengqiy

[sttts]

Lgtm. Giving @jackg @mengqiy some time to take a look.

[sttts]

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: ash2k, sttts

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• staging/src/k8s.io/apimachinery/pkg/OWNERS [sttts]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[k8s-github-robot]

/test all

Tests are more than 96 hours old. Re-running tests.

[k8s-github-robot]

Automatic merge from submit-queue (batch tested with PRs 65094, 65533, 63522, 65694, 65702). If you want to cherry-pick this change to another branch, please follow the instructions here.