This is a general problem that we need to solve better. When an abstract type exposes a common field, we want the user to be able to think about the values for that field in a general way, and to not worry about provider specifics. An example is the MySQL version that is exposed on the abstract MySQLInstance type. We want the user to be able to input something like 5.6 or 5.7 and under the covers during provisioning those values get validated and translated to a provider specific value, such as MYSQL_5_6 for CloudSQL, or 5.6.39 for RDS.

We want a solution that has the following properties:

• we want the app author to be able to get the version that they need for their app
• we don’t want to have to rev any software when new versions are added on the provider/server side (e.g., hard coded "valid value" lists are not good)
• we want a consistent experience across all providers when using the abstract type, the app author shouldn't be thinking about provider specifics (but the admin that is defining concrete resource classes sure can)
• we don’t want the user to be inputting invalid values, but that’s less of a priority since the create call could just fail downstream later with hopefully a good error message