Support Arbitrary Plugin JsonData

[andrewm-aero]

Is your feature request related to a problem? Please describe.
The jsonData field in the GrafanaDatasource CRD is unnecessarily limiting. Grafana has a plugin architecture, so it is simply not possible to have a field for validation for every plugin. Even if there was a bot that periodically scraped the list of all published plugins, and updated the CRD code to include every field for every plugin (no small feat), this would preclude compatibility with unpublished plugins, effectively making the operator unusable for situations that require in-house plugins.

(If applicable)If your feature request solves a bug please provide a link to the community issue
N/A, but a quick search shows there to be several issues filled requesting to add fields for new plugins, which demonstrates the point.

Describe the solution you'd like
Please add a field, e.g. customJsonData to the GrafanaDatasource CRD, which is an arbitrary map, which, if present, and jsonData is empty, is used verbatim as the jsonData field of the datasource, with no validation. Likewise for customSecureJsonData.

Describe alternatives you've considered
The only other solution is to make it explicit that the operator only supports a limited set of plugins, and to document that exact list prominently.

Additional context
Grafana's own API treats these as arbitrary maps: https://github.com/grafana/grafana/blob/23956557d8c6a119b7de5be5c42024e29634d002/pkg/services/provisioning/plugins/types.go#L18

Existing solutions
N/A

[pb82]

@andrewm-aero if I remember correctly, there was a problem with CRD generation when using a map. But that was on an older version of the operator-sdk. I can try it again. Not sure if there is any other good reason for whitelisting every single new field.

[andrewm-aero]

If arbitrary maps aren't permitted as fields, a workaround would be to make those fields strings, and parse it as JSON within the operator.

[pb82]

I'll give this a try with a map[string]string. I can't see a reason at the moment for not doing that, I will report back with the results.

[NissesSenap]

@pb82 have you had a chance to look in to this?

[meln5674]

This doesn't appear to have gone anywhere since, however, in my travels, I found found that the "correct" way to do this is with a encoding/json.RawMessage field with a set of kubebuilder/operator-sdk markers, which leaves the data as a marshaled string, but still performs basic syntax validation. The catch is that it requires updating to controller-gen 0.6.2 . Not sure how you folks feel about that.