I just wanted to express a thought too: I appreciate the fact that Pulumi leverages the upstream providers and are built automatically, but these kind of oddball edge cases that escape the Pulumigen logic are quite annoying. It’s nice that Pulumi wants to leverage the providers, but why isn’t Pulumi just forking these and maintaining them in the pulumi community? This isn’t the first provider I’ve hit my head on where the pulumigen code works on the surface, but something under the covers changes the way it operates at a lower level call... https://github.com/pulumi/pulumi-fastly/issues/119 But when I run into this, I lose faith in the concept that “terraform providers just kinda work with pulumi” — because they don’t, really… and a new version of the pulmi provider shouldn’t always be released simply because terraform updated the upstream. I know this is a quirk I Just don’t know how to go about avoiding it..

Hey Thomas. Firstly, let me apologise for the poor experience here. As you note, sometimes we're privy to the issues with upstream providers and this is as a result of the bridging mechanism. It's rare there a bugs purely in the Pulumi bridge, and often the issues arise in the provider as you noted. As for your question about maintaining providers, the reason is primarily due to the engineering work it would take to manage and maintain so many provider forks. Our chosen path is to release and manage providers using API specs, as we are with the Azure, Google (beta) and AWS (in progress) providers. Obviously this doesn't help in this case With regards to your comment about updating the provider, we obviously want to get some of the new features in the tf provider, if you're running into issues I'd really recommend pinning your language SDKs to known good versions that work for you using

package.json

|

requirements.txt

|

go.mod

Yeah we do use Pipenv with a Pipfile and lock to pin to 3.4.x.