You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
TL;DR:
JSON does not support Int64 well. The current recommendation is that anyone using the count or capacity values should avoid using extremely large numbers.
Issue with setting count or capacity for Counter to max(int64):
When the Counter capacity or count are set to max(int64) in the game server spec and running kubectl create -f fleet.yaml we get an error: spec.template.spec.counters.sessions.capacity: Invalid value: "number": spec.template.spec.counters.sessions.capacity in body must be of type integer: "number"
When the Counter capacity or count in the game server spec are close to, but not at, max(int64) kubectl create does not error. However, when checking the details of the game server with kubectl describe the values are truncated:
@zmerlynn root-caused the issue #3608, and found that the source issue is with jsonpatch translating values to scientific notation. A different repo ran into the same error and has a longer description of the issue evanphx/json-patch#189. We're unable to switch to this repo because the fixed method CreateMergePatch just gives back bytes, but in tests, etc. we use the jsonpatch structures. This will likely need to be an upstream fix in gomodules/jsonpatch or kubernetes-sigs/json. The takeaway is that JSON does not support int64 well, and if the controller is having this many issues there are likely other issues that would crop up elsewhere in the code, and other languages would have yet another set of issues.
The text was updated successfully, but these errors were encountered:
It's better we're on the same project that controller-runtime uses so we
can take advantage of any upstream security and bugfixes that may occur
- or have occurred already!
Work on googleforgames#3636 - since if that issue gets fixed, it will get fixed here.
Also, it ws a fun little fix to work on 😃
It's better we're on the same project that controller-runtime uses so we
can take advantage of any upstream security and bugfixes that may occur
- or have occurred already!
Work on #3636 - since if that issue gets fixed, it will get fixed here.
Also, it ws a fun little fix to work on 😃
Co-authored-by: Zach Loafman <zml@google.com>
TL;DR:
JSON does not support Int64 well. The current recommendation is that anyone using the
count
orcapacity
values should avoid using extremely large numbers.Issue with setting count or capacity for Counter to max(int64):
When the Counter
capacity
orcount
are set to max(int64) in the game server spec and runningkubectl create -f fleet.yaml
we get an error:spec.template.spec.counters.sessions.capacity: Invalid value: "number": spec.template.spec.counters.sessions.capacity in body must be of type integer: "number"
When the Counter
capacity
orcount
in the game server spec are close to, but not at, max(int64)kubectl create
does not error. However, when checking the details of the game server withkubectl describe
the values are truncated:becomes
Debugging:
@zmerlynn root-caused the issue #3608, and found that the source issue is with
jsonpatch
translating values to scientific notation. A different repo ran into the same error and has a longer description of the issue evanphx/json-patch#189. We're unable to switch to this repo because the fixed methodCreateMergePatch
just gives back bytes, but in tests, etc. we use the jsonpatch structures. This will likely need to be an upstream fix in gomodules/jsonpatch or kubernetes-sigs/json. The takeaway is that JSON does not support int64 well, and if the controller is having this many issues there are likely other issues that would crop up elsewhere in the code, and other languages would have yet another set of issues.The text was updated successfully, but these errors were encountered: