Providers support validating an entire practitioner configuration in either declarative or imperative logic. Feedback, such as required syntax or acceptable combinations of values, is returned via diagnostics.
This page describes implementation details for validating entire provider configurations, typically referencing multiple attributes. Further documentation is available for other configuration validation concepts:
Configuration validation in Terraform occurs without provider configuration ("offline"), so therefore the provider Configure method will not have been called. To implement validation with a configured API client, use logic within the Configure method, which occurs during Terraform's planning phase.
The provider.ProviderWithConfigValidators interface follows a similar pattern to attribute validation and allows for a more declarative approach. This enables consistent validation logic across multiple providers. Each validator intended for this interface must implement the provider.ConfigValidator interface.
During execution of the terraform validate, terraform plan and terraform apply commands, Terraform calls the provider ValidateProviderConfig RPC, in which the framework calls the ConfigValidators method on providers that implement the provider.ProviderWithConfigValidators interface.
The terraform-plugin-framework-validators Go module has a collection of common use case provider configuration validators in the providervalidator package. These use path expressions for matching attributes.
This example will raise an error if a practitioner attempts to configure both attribute_one and attribute_two:
// Other methods to implement the provider.Provider interface are omitted for brevity
type ExampleCloudProvider struct {}
func (p ExampleCloudProvider) ConfigValidators(ctx context.Context) []provider.ConfigValidator {
return []provider.ConfigValidator{
providervalidator.Conflicting(
path.MatchRoot("attribute_one"),
path.MatchRoot("attribute_two"),
),
}
}
The provider.ProviderWithValidateConfig interface is more imperative in design and is useful for validating unique functionality across multiple attributes that typically applies to a single provider.
During execution of the terraform validate, terraform plan and terraform apply commands, Terraform calls the provider ValidateProviderConfig RPC, in which the framework calls the ValidateConfig method on providers that implement the provider.ProviderWithValidateConfig interface.
This example will raise a warning if a practitioner attempts to configure attribute_one, but not attribute_two:
// Other methods to implement the provider.Provider interface are omitted for brevity
type ExampleCloudProvider struct {}
type ExampleCloudProviderModel struct {
AttributeOne types.String `tfsdk:"attribute_one"`
AttributeTwo types.String `tfsdk:"attribute_two"`
}
func (p ExampleCloudProvider) ValidateConfig(ctx context.Context, req provider.ValidateConfigRequest, resp *provider.ValidateConfigResponse) {
var data ExampleCloudProviderModel
resp.Diagnostics.Append(req.Config.Get(ctx, &data)...)
if resp.Diagnostics.HasError() {
return
}
// If attribute_one is not configured, return without warning.
if data.AttributeOne.IsNull() || data.AttributeOne.IsUnknown() {
return
}
// If attribute_two is not null, return without warning.
if !data.AttributeTwo.IsNull() {
return
}
resp.Diagnostics.AddAttributeWarning(
path.Root("attribute_two"),
"Missing Attribute Configuration",
"Expected attribute_two to be configured with attribute_one. "+
"The provider may return unexpected results.",
)
}
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4