or just the tfbridge binary
# contribute
a
or just the tfbridge binary
s
My understanding is a resource provider has a specific grpc interface, and that tfgen is one way to generate a provider and it’s accompanying SDKs to implement it. You can also write non-Terraform-based providers which implement the interfaces directly like the Kubernetes one.
a
oh cool the Kubernetes provider is not based on tfgen because tfgen is only used to parse a tf provider and generate an SDK.
I just need confirmation that on a high level, a Pulumi provider based on a Terraform provider is wrapping the terraform provider and using rpc to communicate with it for CRUD operations.
And a Pulumi provider not based on a Terraform provider like the k8s one is implementing "by hand" all the CRUD operations instead of communicating with an underlying Terraform provider
And every provider is using rpc to communicate with the pulumi engine
s
Yes that is correct
There may be slightly more nuance that I haven’t got into (likely one of the Pulumi team can clarify that!) but that is my understanding
a
thanks again @stocky-spoon-28903
s
👍
b
You both have the right of it now. The GRPC interface that the providers implement is here: https://github.com/pulumi/pulumi/blob/master/sdk/proto/provider.proto
c
Yes, just to be super clear, btw: the Kubernetes provider is 100% TF-free.
🙂