Edit: Since typing this up, I’ve realized that validation doesn’t require the provider’s Configure() method to run at all, so the idea of validating the configuration based on facts (the API version) learned in the provider’s Configure() isn’t going anywhere.
I’m less sure about whether that constraint applies to plan modification. If Configure() could leave some breadcrumbs for ModifyPlan(), that would still be interesting.
Original post follows
I’ve run into a couple of situations with small differences between API versions which I could be handling more gracefully.
Examples:
- An attribute is optional in one version of the API, but required in another version. I’d like to catch missing user input during validation.
- An attribute is only valid in one version of the API, and I’d like to default it for that version, while keeping the default value out of the state if talking to other API versions.
The provider discovers the API version in its Configure() method, but I haven’t found a way to make the discovered API version available to any of these:
- an attribute validator
- a resource’s (or data source’s)
ValidateConfig() - a resource’s (or data source’s)
ModifyPlan()
How can the provider’s Configure() leave a clue about the API version for the validation and plan modification code?
Should I be thinking about this a different way?