Typed parameter support

[mpereira]

What would you like to be added:

Support for boolean, array, integer, float params.yaml parameters.
Bonus points for object type support.

Why is this needed:

Configuration files for KUDO operators (potentially YAML templates) usually
require array or object settings. Being able to more easily template in arrays
and objects, and to use booleans directly as template predicates instead of
using text equality to "true" or "false" strings would be nice.

Adding typed setting support also sets the stage for parameter validation. For
example, integer values might validate bounds checking in the form of
mininum and maximum fields.

NODE_COUNT:
  description: "Number of Cassandra nodes."
  type: "integer"
  default: 3
  minimum: 1

Or enum validation for optional string types:

DISK_OPTIMIZATION_STRATEGY:
  description: "The strategy for optimizing disk reads"
  type: "string"
  default: ""
  required: false
  enum:
    - "ssd"
    - "spinning"

[gerred]

👍 to this. It's potentially a pretty big story. Not sure if we'll need to use reflect here.

I'm tempted to wait on this until we can make typed CRDs for each operator, because then we can generate and take advantage of CRD OpenAPIv3 specs.

[mpereira]

Should we work on a KEP for this?

[mpereira]

I just noticed that there's a "needs KEP" label... 🙂

[kensipe]

There is a need for KEP... and perhaps we should look at params / values as a whole (in that KEP).

[porridge]

Support for boolean, array, integer, float params.yaml parameters.

Support for array of anything might be much more involved than, say, support for arrays of strings only. What use cases did you have in mind @mpereira ?

Bonus points for object type support.

What about maps?