-
Notifications
You must be signed in to change notification settings - Fork 41.1k
Preserve string form if the original value can be fully represented #133238
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
base: master
Are you sure you want to change the base?
Conversation
Signed-off-by: Tamal Saha <[email protected]>
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the The 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-sigs/prow repository. |
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: tamalsaha 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 |
I think it's a won't-fix feature. See the referenced link for detail: |
cc @liggitt |
that's actually sort of a problem, since ~all typed go clients and ~all historical servers will canonicalize it currently changing mid-stream means version-skewed servers in the same cluster will persist different things into etcd for the same API request, which isn't great, and round-tripping non-canonical API responses through typed clients will canonicalize them on update... I'm not sure if that will trip up immutable-on-update field validations |
@@ -365,6 +365,13 @@ func ParseQuantity(str string) (Quantity, error) { | |||
amount.Neg(amount) | |||
} | |||
|
|||
copyAmount := new(inf.Dec) |
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 is secondary to the bigger question of whether we even can/should change the canonicalize-on-serialize behavior, but making a second object and doing a comparison seems like a roundabout (no pun intended) and possible expensive way of determining if we lost precision ... do we really not know if we lost precision in the parsing otherwise?
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.
do we really not know if we lost precision in the parsing otherwise?
I don't know if there is a better / more performant way. Looking at the signature of the .Round()
methods, I don't see anything that says if the value was actually rounded or not.
If Quantity were just now being introduced, preserving the input string as-is when it is fully representable would seem like a good idea to me. However, since the canonicalize-on-write behavior has existed in the wild for a decade now, both in clients and servers, I think removing that behavior is likely to cause problems. Thanks for the PR, but I don't think we should proceed with this change. cc @deads2k |
The input string format is preserved in some scenarios where it can be fully represented by the integer part. See L 335, L339 It is not preserved in when the decimal representation is used as the value might have been truncated. |
Right, I mean that changing when canonicalization is applied is difficult to reason about the affect it will have interoperating with existing clients and servers that apply canonicalization differently. |
What type of PR is this?
/kind feature
What this PR does / why we need it:
resource.Quantity
does not preserve the input string format in case of internal decimal presentation. For example,will print
1181116006400m
. This pr will print the original input string"1.1Gi"
, as it can be fully represented internally.One of the side effect of this change is that it will not automatically "canonicalize" the input string format. For example,
".001Ki"
will not convert into"1024m"
anymore. You can see the changes done in tests for more examples.IMHO, this change is ok, because in handwritten YAMLs,
"1.1Gi"
are lot more common than".001Ki"
.Which issue(s) this PR is related to:
Special notes for your reviewer:
Does this PR introduce a user-facing change?
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.: