Skip to content

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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

tamalsaha
Copy link
Member

@tamalsaha tamalsaha commented Jul 26, 2025

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,

func main() {
	q := resource.MustParse("1.1Gi")
	fmt.Println(q.String())
}

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?

Preserve string form if the original resource.Quantity value can be fully represented

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:


@k8s-ci-robot k8s-ci-robot added kind/feature Categorizes issue or PR as related to a new feature. size/S Denotes a PR that changes 10-29 lines, ignoring generated files. do-not-merge/release-note-label-needed Indicates that a PR should not merge because it's missing one of the release note labels. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. do-not-merge/needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. labels Jul 26, 2025
@k8s-ci-robot
Copy link
Contributor

This issue is currently awaiting triage.

If a SIG or subproject determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

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.

@k8s-ci-robot k8s-ci-robot added needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. needs-priority Indicates a PR lacks a `priority/foo` label and requires one. sig/api-machinery Categorizes an issue or PR as relevant to SIG API Machinery. and removed do-not-merge/needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. labels Jul 26, 2025
@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: tamalsaha
Once this PR has been reviewed and has the lgtm label, please assign smarterclayton for approval. For more information see the Code Review Process.

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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@k8s-ci-robot k8s-ci-robot requested review from saad-ali and thockin July 26, 2025 22:15
@k8s-ci-robot k8s-ci-robot added release-note Denotes a PR that will be considered when it comes time to generate release notes. and removed do-not-merge/release-note-label-needed Indicates that a PR should not merge because it's missing one of the release note labels. labels Jul 26, 2025
@ylink-lfs
Copy link
Contributor

ylink-lfs commented Jul 27, 2025

@BenTheElder
Copy link
Member

cc @liggitt

@liggitt
Copy link
Member

liggitt commented Jul 29, 2025

One of the side effect of this change is that it will not automatically "canonicalize" the input string format

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

@liggitt liggitt Jul 29, 2025

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?

Copy link
Member Author

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.

@liggitt
Copy link
Member

liggitt commented Jul 29, 2025

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

@tamalsaha
Copy link
Member Author

tamalsaha commented Jul 29, 2025

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.

The input string format is preserved in some scenarios where it can be fully represented by the integer part. See L 335, L339
https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/apimachinery/pkg/api/resource/quantity.go#L335-L339

It is not preserved in when the decimal representation is used as the value might have been truncated.

@liggitt
Copy link
Member

liggitt commented Jul 30, 2025

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. kind/feature Categorizes issue or PR as related to a new feature. needs-priority Indicates a PR lacks a `priority/foo` label and requires one. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. release-note Denotes a PR that will be considered when it comes time to generate release notes. sig/api-machinery Categorizes an issue or PR as relevant to SIG API Machinery. size/S Denotes a PR that changes 10-29 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants