allow kubebuilder:validation:Schemaless marker on types

[Diaphteiros]

We have the the following custom struct which wraps json.RawMessage:

type AnyJSON struct {
	json.RawMessage `json:",inline"`
}

func (s AnyJSON) MarshalJSON() ([]byte, error) {
	return s.RawMessage.MarshalJSON()
}

func (s *AnyJSON) UnmarshalJSON(data []byte) error {
	if string(data) == "null" {
		*s = AnyJSON{RawMessage: nil}
		return nil
	}

	raw := json.RawMessage{}
	if err := raw.UnmarshalJSON(data); err != nil {
		return err
	}
	*s = AnyJSON{RawMessage: raw}
	return nil
}

It is used both directly and also as value of a map:

Configuration *AnyJSON `json:"config,omitempty"`
Configurations map[string]AnyJSON `json:"configurations,omitempty"`

Without any markers, the result is an error message during generation:

conflicting types in allOf branches in schema: string vs object

So I added these markers:

// +kubebuilder:pruning:PreserveUnknownFields
type AnyJSON struct {
	// +kubebuilder:validation:Schemaless
	json.RawMessage `json:",inline"`
}

While this fixes the generation problem, the generated CRD looks like this (for the map example above, I removed the description to improve readability):

          configurations:
            additionalProperties:
              type: object
              x-kubernetes-preserve-unknown-fields: true
            type: object

This means that the map values must be objects, despite the AnyJSON struct being able to hold arbitrary JSON, thus preventing the CRD from working as desired. I would like to simply have no type definition within the additionalProperties struct here.

---

I have not found a solution for this problem except for adding the +kubebuilder:validation:Schemaless marker to any field that uses the AnyJSON struct. This is highly annoying and prone to causing problems when adding new types.

Since the proposal to add multi-types already got denied (see #735), would it be possible to enable adding the kubebuilder:validation:Schemaless marker to a type? This way, I could add the marker once to the type definition and would not have to add it every single time the type is used.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale