handle preserve-unknown-fields

[clux]

via https://twitter.com/matteojoliveau/status/1490747666707496961

A CRD that sets x-kubernetes-preserve-unknown-fields can effectively put whatever they want into the schema without specifying it in the schema.

Currently, kopium does not generate anything for this CRD, and this property is not handled at all.

We should handle the property, and where it is seen, it should include an arbitrary json value that can be flattened into the struct as a member:

struct FooSpecWithPreserveProperty {
    #[serde(flatten)]
    pub unknowns: serde_json::Value,
}

---

This is probably not that bad to for a new contributor to try out as it's mostly just work in the analyzer.
In particular, it requires more logic in the initial type examination to handle the extra property, but probably a bit subtlety since we are not actually examining a member to get the this member and type: we get it from the object instead (if the object has the property, we need this extra overflow type that always looks like the above).

It also needs a test crd, maybe the image.kpack.io thing from the tweet if we can find it, all i can find is a doc spec for it but not the crd.

[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.