'cannot convert int64 to float64' with runtime.DefaultUnstructuredConverter.FromUnstructured on CustomResourceDefinitions with integer minimum, maximum, and/or multipleOf values

[nrb]

What happened:

When converting JSON representations of v1beta1 CustomResourceDefintions with Spec.Validation.OpenAPIV3Schema.Properties.(Minimum|Maximum|multipleOf) fields set to a whole number, the runtime.DefaultUnstructuredConverter.FromUnstructured function returns 'cannot convert int64 to float64'.

Making the field decimal numbers converts as expected.

What you expected to happen:
OpenAPI schema should convert from unstructured.Unstructured whether whole or decimal representation.

How to reproduce it (as minimally and precisely as possible):

A Go test with a minimal CRD & failing test is at https://github.com/nrb/unstructured-conversion-bug/blob/master/main_test.go. The repo includes a go.sum with pinned versions of dependencies. Use go test to run it and get a failure.

Anything else we need to know?:
This was identified by someone reviewing a Velero pull request that waited on CRDs to be 'ready' before restoring CRDs from their serialized JSON representations. The reproduced case is based on his sample CRD.

There's also a Helm 2 issue referencing this, with an included fix. helm/helm#5806.

I believe #77665 may be related, but I'm not 100% sure.

Environment:

• Kubernetes version (use kubectl version): apimachinery 0.17.2

[nrb]

/sig api-machinery

[liggitt]

I don't think number type conversion is intended to be performed by that helper. It's primary purpose is to round-trip between a typed and unstructured object without requiring json serialization/deserialization.

If you have JSON you want to unmarshal, you can do so directly into the CRD go type without first unmarshaling into an Unstructured object.

[fedebongio]

/assign @jennybuckley

[nrb]

@liggitt Apologies for the delayed response.

In the original problem this was actually with information returned by the Kubernetes API server, which I then tried to change into the CRD Go type. The original goal was for Velero (a backup/restore tool) to check a CRD in the cluster for readiness before restoring any CRs. In Velero's case, because we deal with more or less any object that could be in the API server, we're using a Dynamic client as we can't import every possible Go type, though well-known ones like CRDs are different.

The example I have is the simplest possible reproduction case I could come up with, without involving a full Kubernetes API server.

Given we're constrained to using Unstructured types from the Kubernetes API server, is there an alternative method we could use for translating them into the CRD Go types?

[liggitt]

Given we're constrained to using Unstructured types from the Kubernetes API server, is there an alternative method we could use for translating them into the CRD Go types?

I'm not sure I understand. If you're working with go types, you can unmarshal into the typed structs, correct?

[nrb]

Not always, because in some instances, we hit this error. We got another report of this today (vmware-tanzu/velero#2319), which I traced back to my code at https://github.com/vmware-tanzu/velero/blob/master/pkg/backup/remap_crd_version_action.go#L65, the runtime.DefaultUnstructuredConverter.FromUnstructured call to take the Unstructured data to the Go type.

I should clarify - Velero's not working with JSON directly at this point. It's working with unstructured.Unstructured.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[nrb]

/remove-lifecycle-stale

This is still affecting Velero, though we've worked around it by not using FromUnstructured on CRDs returned directly from the Kube API server as Unstructured through a dynamic client. We instead marshal to JSON and back for now.

I think I may have not explained my case clearly - is there anything I can do or provide to help resolve this?

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[liggitt]

apologies for the delay, I dug into this and opened #93250 as a fix

[nrb]

@liggitt Thanks a ton!