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 https://github.com/kubernetes-sigs/controller-tools/issues/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

[k8s-triage-robot]

The Kubernetes project currently lacks enough active 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 rotten
• Close this issue with /close
• Offer to help out with Issue Triage

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

/lifecycle rotten

[sbueringer]

Seems okay to me, @JoelSpeed wdyt?

[JoelSpeed]

@Diaphteiros Can you explain a little more about your use case for the AnyJSON struct? Have you considered at all the runtime.RawExtension as I believe that it's primary use case is when you need schemaless data and want to put "anything" into a field, looks to me like it will act in pretty much the way this AnyJSON concept would

[sbueringer]

In cluster API we use apiextensionsv1.JSON successfully. Tested runtime.RawExtension at the time, but didn't work for us. I don't remember why, maybe it didn't support scalar values?

[k8s-triage-robot]

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

This bot triages 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:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

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

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

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

This bot triages 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:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

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

/close not-planned

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.