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...
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..
also the fastly provider on the terraform side is so poorly done, I dont’ even want to get into it
09/14/2021, 10:12 PM
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
09/14/2021, 10:27 PM
Yeah we do use Pipenv with a Pipfile and lock to pin to 3.4.x.
I will say that the Fastly provider is terrible, even with Terraform so I can’t say this is a Pulumi specific problem.
I’m contemplating just discontinue using it it’s so bad, and just generating VCL myself.
(this specific provider)
@billowy-army-68599 unrelated to the upgrade, but I discovered that the Fastly Terraform provider doesn’t sanity check if you use the same backend “name” key… which bubbles up to the Pulumi bridge of course. 😂 So it means two same-named things in the Servicev1BackendArgs() Sequence [since it’s just a list of objects] will pollute each other as it reads and writes to the API. Brilliant… so I put a sanity check in my own implementation of the provider. 😄