There’s no boilerplate or docs - but it’s not too hard to do if you look at the kubernetes provider.
Here’s a mail I sent recently on this with some details - planning on moving this into docs and/or boilerplate soon.
We have plans to make this easier in two dimensions - a schema driven model for building providers, and a shared code generator so you don’t have to reimplement yourself.
——————
Here's a quick summary of the pieces of building a native Pulumi provider. I'll use the Kubernetes provider as an example.
First - there are two pieces to any provider:
* A provider binary which serves the Resource Provider gRPC interface
* An SDK per Pulumi language that projects the resources managed by the provider into NodeJS, Python, .NET, Go, etc.
In the Kubernetes provider - there are two binaries corresponding to the above:
The provider binary:
https://github.com/pulumi/pulumi-kubernetes/blob/master/cmd/pulumi-resource-kubernetes/main.go
To generate the language SDKS:
https://github.com/pulumi/pulumi-kubernetes/blob/master/cmd/pulumi-gen-kubernetes/main.go
Any resource provider will generally be driven off of some form of Schema. This can differ based on the resources being mapped. For Kubernetes, the schema is the published OpenAPI spec for the Kubernetes API Server. For Terraform-bridged providers it is the Terraform resource schema. And it can also be any sort of homegrown schematization if needed. This schema describes what resources exist, what properties exist on those resources and with what types, and some information about how to map those resources to API calls for CRUD operations.
The gRPC interface that a Pulumi Provider must implement is documented here:
https://github.com/pulumi/pulumi/blob/master/sdk/proto/provider.proto. It is implemented for the Kubernetes provider here:
https://github.com/pulumi/pulumi-kubernetes/blob/master/pkg/provider/provider.go. To first approximation, this is an implementation of Create, Read, Update and Delete operations - but there are also critical Check and Diff functions. The contracts for the implementations of these interfaces are discussed in some detail in
https://www.pulumi.com/docs/intro/concepts/programming-model/#resource-provider-interface in the context of "Dynamic Providers", but are generally the same as for the raw gRPC interface.
For the Kubernetes provider, the code generators are built on top of Mustache templates - and are generatred from the same schema as is used to implement the gRPC interface. In general one class is generated per Resource, which just inherits from the core Pulumi package's CustomResource constructor that takes care of actually registering the resource with Pulumi.