Allow Configuration Validators To Satisfy DataSourceConfigValidator, ProviderConfigValidator, and ResourceConfigValidator Interfaces

[bflad]

Module version

v0.9.0

Use-cases

Provider developers may wish to develop generic "top level" schema data based configuration validators that satisfy all the following interfaces:

• tfsdk.DataSourceConfigValidator
• tfsdk.ProviderConfigValidator
• tfsdk.ResourceConfigValidator

Such as these:

• Conflicting Multiple Attribute Validation (ConflictsWith / ConflictingAttributes) terraform-plugin-framework-validators#14
• Exactly One Multiple Attribute Validation (ExactlyOneOf / ExactlyOneAttribute) terraform-plugin-framework-validators#15
• At Least One Multiple Attribute Validation (AtLeastOneOf / AtLeastOneAttribute) terraform-plugin-framework-validators#16
• Required With Multiple Attribute Validation (RequiredWith / CombinationAttributes) terraform-plugin-framework-validators#17

These *ConfigValidator interfaces were originally split during the initial validation implementation to allow separate feature handling, should the protocol individually change over time for one or more of the Validate*Config RPCs. I think the split use cases is very valid and follows the original design principles of this framework, however I made a simple mistake in the actual code for the interfaces, where they each use the same Validate() method name with differently typed parameters. Oops. They should use different method names so all three can be implemented, if desired. The validator developer can choose to share the implementation details across them to reduce code, however that is outside the scope of the framework anyways.

Attempted Solutions

Individual data source, provider, and resource configuration validators. 😢

Proposal

Adjust the interfaces slightly from:

type DataSourceConfigValidator interface {
	// ... other fields ...

	Validate(context.Context, ValidateDataSourceConfigRequest, *ValidateDataSourceConfigResponse)
}

type ProviderConfigValidator interface {
	// ... other fields ...

	Validate(context.Context, ValidateProviderConfigRequest, *ValidateProviderConfigResponse)
}

type ResourceConfigValidator interface {
	// ... other fields ...

	Validate(context.Context, ValidateResourceConfigRequest, *ValidateResourceConfigResponse)
}

To:

type DataSourceConfigValidator interface {
	// ... other fields ...

	ValidateDataSource(context.Context, ValidateDataSourceConfigRequest, *ValidateDataSourceConfigResponse)
}

type ProviderConfigValidator interface {
	// ... other fields ...

	ValidateProvider(context.Context, ValidateProviderConfigRequest, *ValidateProviderConfigResponse)
}

type ResourceConfigValidator interface {
	// ... other fields ...

	ValidateResource(context.Context, ValidateResourceConfigRequest, *ValidateResourceConfigResponse)
}

One potential consideration here is a separate breaking change to refactor data source, provider, and resource specific types into their own packages, but I think this change can be made beforehand without too much repercussions given that these are likely rare in the wild at the moment (as compared to attribute validators) and when that refactoring potentially happens it can just be a breaking change of the type name itself while keeping the newly specific Validate* method names.

References

• Introducing schemavalidator package terraform-plugin-framework-validators#32 (review)

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.