Agreed. I might have a look at that if nobody else does. Not sure what’s involved though. I assume Pulumi builds their own providers and would accept external ones they haven’t already built in-house.
But also there’s a bridged provider package type that allows you to use Terraform as a Pulumi provider? Not sure what the implications on the flexibility of that would be.
And it seems you can also convert Terraform to Pulumi? Truly weird stuff.
Interesting. Maybe Fly have to instigate it.
I sae the Terraform approach too. Fly do have a Terraform provider so maybe that would be the way to get it into Pulumi too. Without duplicating a load of stuff.
Fun fact, a pulumi provider has been attempted but we ultimately chose to set it aside for now. Here is why: as you both correctly noted Pulumi does have a mechanism to bridge a Terraform provider to Pulumi. To understand why we can’t use that to bridge our provider we need to understand a bit of the history behind Terraform Provider development.
When Terraform originally allowed for external providers, developers could use something called the Terraform SDK, the Terraform SDK became SDKV2. The SDK/SDKV2 had a bunch of problems/rough edges that led to the
Terraform Plugin Framework being created. Most major TF Providers are still built on the SDK, while new providers are encouraged to use the new
Terraform Plugin Framework. Because the Fly.io Provider was a greenfield implementation, I used the new Framework.
That brings us back to the Pulumi problem. GitHub - pulumi/pulumi-terraform-bridge: A library allowing providers built with the Terraform Plugin SDK to be bridged into Pulumi. only supports bridging providers built with the old SDK, not the new Framework. Now, it is possible to do a “Pulumi Native” provider, but that feels a lot less supported than the bridge and has several ergonomics problems that made it not fun to work with.
Not to say it can’t be done! We probably just won’t be the ones doing it for now
@DAlperin Thanks, that explains it.