Task-util-config: it should be possible to set a default value for a parameter that depends on one or more parameters different from current value

[dcremonini]

• Kind of request: RFC of a feature request

Problem

Currently the wizard doesn't allow the developer to specify the default value for a single item based on values of other parameters.

Example 1

The minimum amount of RAM to allocate depends on the chosen services.

• If the final user wants to install only PostgreSQL, then the wizard should suggest a minimum amount of RAM (let's say 16 GB).
• If the final user wants to install only PostgreSQL and MinIO, then the wizard should suggest a different minimum amount of RAM (let's say 22 GB).

Example 2

A string might need to be the concatenation of names previously input.

• If a variable ORGNAME name is specified as "ACME", and another variable CLUSTERNAME is specified as "FINANCE", then the suggested value for a variable NODEPREFIX is "ACME-FINANCE".

The implementation of this feature should affect all the types:

• string
• int
• float
• bool

Impact

100% of users that will install the ops would find much easier to install Open Serverless.

Priority

low

Suggested solution for the example 1:

"POSTGRESENABLED": {
  "type": "bool"
},
"MINIOENABLED": {
  "type": "bool"
},
"MINRAM": {
  "type": "",
  "default-function": "calcMinRam"
}

and somewhere else (I show some pseudocode, it might be Typescript):

calcMinRam() {
if (POSTGRESENABLED == True and MINIOENABLED == False {
     return 16;
} else if (POSTGRESENABLED == True and MINIOENABLED == True {
     return 24;
}

If the function specified in "default-function" doesn't return a suitable value (e.g. NaN), a default value can be considered (see #61)

With
POSTGRESENABLED not enabled
and
MINIOENABLED not enabled the calcMinRam function wouldn't return a suitable value so the value 14 should be considered (see example below):

"MINRAM": {
  "type": "",
  "default": "14",
  "default-function": "calcMinRam"
}

Alternative solution

The implementation of this feature request might be overly complex.
Alternative solution: an explanation in the label might be enough.