✨ Add crd:validation:Schemaless marker

[maxsmythe]

This marker will avoid trying to do any type detection on any struct field on which it is set. This gives users a safety valve when they hit an edge case where type inference does the wrong thing for them.

This fixes #291, which was recently re-broken by fixing #502

Signed-off-by: Max Smythe smythe@google.com

[k8s-ci-robot]

Welcome @maxsmythe!

It looks like this is your first PR to kubernetes-sigs/controller-tools 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes-sigs/controller-tools has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

[lkysow]

We have a situation where we want to model map[string]interface{}, e.g.

spec:
  config: # we want this to be map[string]interface
    foo: '{some-fun-json}'
    members: 3

Currently we're using:

	Config json.RawMessage `json:"config,omitempty"`

And then converting to map[string]interface{}.

func (in *ProxyDefaults) convertConfig() map[string]interface{} {
	if in.Spec.Config == nil {
		return nil
	}
	var outConfig map[string]interface{}
	json.Unmarshal(in.Spec.Config, &outConfig)
	return outConfig
}

The only CRD type we've found that works is object:

          properties:
            config:
              description: yada
              type: object

However the CRD generation gives us:

            config:
              description: yada
              format: byte
              type: string

If we use the annotation

	// +kubebuilder:validation:Type=object
	Config json.RawMessage `json:"config,omitempty"`

We get an error:

github.com/hashicorp/consul-k8s/api/v1alpha1:-: conflicting types in allOf branches in schema: string vs object

Would this change allow us to do:

	// +kubebuilder:validation:Type=object
        // +kubebuilder:validation:Schemaless
	Config json.RawMessage `json:"config,omitempty"`

?

[maxsmythe]

It should be able to.

Some alternatives for you:

• Use runtime.RawExtension to wrap an object one level higher, and user XPreserveUnknownFields to allow any field to be set on that object. You will need to do the serialization/deserialization yourself if you do this.
• Consider a different API design, as maps of objects accepting arbitrary fields is against the K8s API Conventions, though this is certainly not universally applied.

If neither of these alternatives work for you, this PR would be helpful.

[DirectXMan12]

minor comment on a go modules file change, otherwise lgtm

[DirectXMan12]

??

[maxsmythe]

That had fixed an error I was having running the linter. It's been a while, so I can't remember what the error was.

Testing again with this line re-added doesn't cause a problem anymore. I wonder if it only breaks if your go modules aren't already up-to-date?

In any case, not really in scope for this PR, so reverting.

[DirectXMan12]

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: DirectXMan12, maxsmythe

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [DirectXMan12]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[maxsmythe]

Thanks!