Change:
reflect.Uint, reflect.Uint8, reflect.Uint16, reflect.Uint32, reflect.Uint64: dv.Set(sv.Convert(dt)) return nil <ins> case reflect.Float32, reflect.Float64: dv.Set(sv.Convert(dt)) return nil </ins> } case reflect.Float32, reflect.Float64: switch dt.Kind() {

Discussion:
What happened: When converting JSON representations of v1beta1 CustomResourceDefintions with fields set to a whole number, the 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 The repo includes a with pinned versions of dependencies. Use to run it and get a failure. Anything else we need to know?: This was identified by someone reviewing a 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. I believe may be related, but I'm not 100% sure. Environment: Kubernetes version (use ): apimachinery 0.17.2
/sig api-machinery
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.
/assign
Apologies for the delayed response. In 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?
I'm not sure I understand. If you're working with go types, you can unmarshal into the typed structs, correct?

Not always, because in some instances, we hit this error. We got another report of this today (), which I traced back to my code at , the 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 .
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle-stale This is still affecting Velero, though we've worked around it by not using 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?
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
apologies for the delay, I dug into this and opened as a fix
Thanks a ton!