handle preserve-unknown-fields

[kube-rs]

handle preserve-unknown-fields

[alex-hunt-materialize]

This is especially relevant for things that expect arbitrary labels, like the very common matchLabels property.

                  matchLabels:
                    type: object
                    x-kubernetes-preserve-unknown-fields: true

This currently creates an empty struct.

Complete CRD is available at https://gist.github.com/alex-hunt-materialize/2743b1e2e58a49c4df0a11ecb39f46ab (generated by the Linkerd 2.11 helm chart).

[alex-hunt-materialize]

Would it potentially make sense to have separate handling for "simple" cases like the above, where there are no named properties of the object?

In this case, it would make sense to have it be a BTreeMap<String, serde_json::Value> rather than a separate struct (really a BTreeMap<String, String>, but nothing in the CRD actually tells us that).

I suspect that the majority of x-kubernetes-preserve-unknown-fields: true use cases are "simple" like that, and this would avoid the need to mess with serde(flatten) or to have additional struct nesting for the client.

#42

[clux]

Yeah, I think you are right. The common map case is the more important one here, and we can leave the degenerate case for another issue (because it's a bit hairy, we can't have the top level spec type be a BTreeMap because we can't impl on that)

Incidentally, we had a similar question on how to proceed with the basic case kube-rs/kube#844 (comment) (for now we only did the map case).

[clux]

Another case that needs to be handled: status objects. The istio destinationrule crd (now included) defines this status object:

          status:
            type: object
            x-kubernetes-preserve-unknown-fields: true

which fails because it sets #[kube(status = "DestinationRuleStatus")] so it also needs some trivial wrapper struct.