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

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"`

?

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.

/lgtm
/approve

[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

Thanks!