Is your feature request related to a problem? Please describe.
The types for arguments can be confusing. Sometimes it is expected to give a terraform map of values, sometimes a yaml string of values, sometimes a json string of values, sometimes a list of strings. It can be hard to keep track of how to send in data.
Describe the solution you'd like
If a terraform map is required it should have a nested type. Terraform lists should not be used as input types. This results in either a nested type that is well documented or a string input. The string inputs should be as simple as possible, if the user needs to send in a full config it probably should be a nested type. A good indicator for this is if the developer finds it simpler to write a blind loop through the keys than expressing the keys individually. If blind loop then probably should be a nested type.
Describe alternatives you've considered
Alternatively, allow users to send in config files directly rather than as input values. If you need to parse the file for some reason then it should probably be a terraform type, but if you are just sending it over to the Rancher API, then just ask for the file contents. This can also be used if the Rancher API has very good concise documentation on the format of the config, just point users to that documentation and assume proper formatting, if the API throws an error due to the format, surface it to the user so they can read the Rancher documentation.
Is your feature request related to a problem? Please describe.
The types for arguments can be confusing. Sometimes it is expected to give a terraform map of values, sometimes a yaml string of values, sometimes a json string of values, sometimes a list of strings. It can be hard to keep track of how to send in data.
Describe the solution you'd like
If a terraform map is required it should have a nested type. Terraform lists should not be used as input types. This results in either a nested type that is well documented or a string input. The string inputs should be as simple as possible, if the user needs to send in a full config it probably should be a nested type. A good indicator for this is if the developer finds it simpler to write a blind loop through the keys than expressing the keys individually. If blind loop then probably should be a nested type.
Describe alternatives you've considered
Alternatively, allow users to send in config files directly rather than as input values. If you need to parse the file for some reason then it should probably be a terraform type, but if you are just sending it over to the Rancher API, then just ask for the file contents. This can also be used if the Rancher API has very good concise documentation on the format of the config, just point users to that documentation and assume proper formatting, if the API throws an error due to the format, surface it to the user so they can read the Rancher documentation.