When building your own provider, what's the link between the Provider and the SDK? More explicitly, when I run a pulumi action (e.g.

pulumi preview

). Pulumi knows to download and install the appropriate provider for the SDKs i'm using in my Pulumi project.

A lot of Pulumi is centered around the Pulumi schema of a provider. Within the schema, you have the

pluginDownloadURL

containing the storage location of the provider binary. Every SDK has the schema bundled, which is how it can find out about the location. For some of the SDK packages, we have package dependent hooks which downloads this provider binary during the package install. E.g. for JS/TS NPM packages, we consistently have an

install

script: https://github.com/pulumi/pulumi-azure-native/blob/master/sdk/nodejs/package.json#L16

@limited-rainbow-51650 how would I for example test my plugin locally?

If you have built the provider binary locally, and it is named

pulumi-resource-<yourname>

, then make sure it is on your

PATH

and you should be good to go to test locally.

Thanks @limited-rainbow-51650

Is this when running locally? Are you bridging an existing TF provider or are you developing a native one?

I'm developing a native one

Did you bootstrap from this template? https://github.com/pulumi/pulumi-provider-boilerplate

I didn't, no. I've just been cobbling pieces together based on the pulumi providers i've seen. Taking some inspiration from the pulumi aws native provider.

We are aware we have to make this whole provider development much more simple. Is it an option to restart your effort using the boilerplate repo, initialize it using these instructions, and then overlay your existing code on top of it?

I can do that.

Please do! We want to know what are the hurdles you run into.

Thank you kindly! Will do

Good luck! And curious what you are building… 😉

At the moment, it's a POC for an provider to be used internally

Nice to hear you leverage the provider development path to manage internal APIs! 🎉