-
Notifications
You must be signed in to change notification settings - Fork 975
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
🔧 Add framework provider #2347
🔧 Add framework provider #2347
Conversation
59a358d
to
d9b0b40
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just left some comments, but generally I'd recommend adding some acceptance tests around how the provider behaves when configured in different ways. Even though this PF provider isn't doing anything (i.e. manages no resources in the provider, yet) it will affect users experience when configuring the provider in their projects and any discrepancy between the two implementations of the provider configuration logic will affect users
framework/provider/provider_test.go
Outdated
// CLI command executed to create a provider server to which the CLI can | ||
// reattach. | ||
var testAccProtoV6ProviderFactories = map[string]func() (tfprotov6.ProviderServer, error){ | ||
"kubernetes": providerserver.NewProtocol6WithError(New("test")), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here protocol 6 is in use, but elsewhere protocol 5 is in use- is that intentional?
And both Alex and I discussed protocol 6 recently and how it requires use of TF v1.0+. If you're adding use of protocol 6 you might need to give users a heads up, as some users do stick with old TF versions for whatever reason.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not intentional – this came from the scaffolding repo. I'll change it to 5 for now.
@@ -51,6 +51,13 @@ func (s *RawProviderServer) PrepareProviderConfig(ctx context.Context, req *tfpr | |||
return resp, nil | |||
} | |||
|
|||
// GetMetadata function | |||
func (s *RawProviderServer) GetMetadata(ctx context.Context, req *tfprotov5.GetMetadataRequest) (*tfprotov5.GetMetadataResponse, error) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not related to the PR, but I'm curious if this function call has to be a singleton among the muxed provider servers.
Could we change the structure here a bit a move this new provider under |
Description
This PR adds a new provider project using Terraform Plugin Framework and muxes with the main and manifest provider. The provider currently does nothing except provide the same provider block configuration interface as the other 2 providers. This provider will be used as a target for code generation.
Acceptance tests
Output from acceptance testing:
Release Note
Release note for CHANGELOG:
References
Community Note