This message was deleted.

It was suggested internally to maybe write a terraform provider and then use your bridge to convert it to a pulumi provider... is that a valid method or is the bad taste that puts in my mouth justified? lol

I think this is what you are looking for: https://github.com/pulumi/pulumi-provider-boilerplate

thank you!

@bored-oyster-3147 what kinda provider are you trying to write? We currently have two kinds - tf-bridged providers (based on a tf schema) and native providers (based on openapi specs) @broad-dog-22463 might be the person with the most info here

what would implementing https://github.com/pulumi/pulumi-provider-boilerplate fall under? Cause that would seem to be neither native or tf-bridged

The README does imply “native”

This repo is a boilerplate showing how to create a native Pulumi provider

Ah, I guess I was confused then because I thought

native

was only generated from an open api spec

@bored-oyster-3147 what provider are you thinking of writing?

The ones currently in rotation (kubernetes, azure-native and gcp-native) are based on openapi specs. or at least k8s and azure-native are. In any case, I guess that’s not strictly necessary

We just have some internal resources that we would like to be part of the pulumi deployment cycle for the purpose of automation. Probably a very low number of resources, so fairly lightweight. Honestly a dynamic provider would probably be best, but we're a .NET shop so can't do that without disconnecting it from all of our existing code. So we just want to be able to put together something light weight, or at least figure out what the best course of action is to do that

@red-match-15116 is 100% correct here - a native provider jsut means that it's a non-TF based provider. You can have your own logic in there that does things

Gotcha, that makes sense. Ok so we'll take a deeper look at that then and see if we can put something together. Looks like it's time to learn Go! lol. thanks everyone

let me know if you need anything here!