Comment 2 for bug 1881916

Mentioned this in the original case as well:
"The reason for this request is because the parameters field the way it is defined makes it sound like it should support the ability to pass in any var. It's not until you dig into the actual underlying values that you see it was really only added to support the storage piece. This discrepancy leads me to believe it was created with the idea of expanding its use in the future. I would consider this as either a feature request or possibly an update to documentation."

To fully answer the question, in the short-term this is a request to update the documentation such that the field causes less confusion. In the long-term however, I would consider this to be our main request for commissioning scripts. Without additional parameter types creating scripts that work dynamically with different skus becomes rather tedious. To further expound on this, provided is the example given in the case.

"... we have two commissioning scripts created, for Dell and Supermicro, to update Bios/Bmc. These scripts support different skus, we do this by defining a list of dicts (in python) containing the values necessary for an update. That python is then imported into the main python script and run through templating to output a switch case statement using ifs based off the mainboard product, which is then injected into the com script and uploaded. There are other other pieces that are injected as well, such as for supermicro the are variations of the bios config that could be applied. This would be easy to solve if we could have the python decide which config is correct and then pass it in as a parameter that gets picked up by the script. However because that isn't available we have to make another switch case for each of the skus and at the top keep a constant tally on which config belongs to which host."

Hopefully this helps understand the reasoning behind the request. Also, using this as an example, it would be a decent idea for support to include a link to the case, if that is where the request originates.

TL;DR, yes improving the explanation in the docs would be a solution for this case.