:pulumi-logo: Introducing: Support For Using Any T...
# announcements
w
pulumi logo Introducing: Support For Using Any Terraform Provider with Pulumi Today we announced a significant new capability in the core Pulumi IaC platform, enabling any Terraform (or OpenTofu) provider to be used with Pulumi. • This is great for Pulumi users who now get access to the long tail of thousands of cloud and SaaS platforms that the open source community has created providers for. • And it is great for cloud providers and internal platform teams who have invested in building these providers, who can now reach the entire Pulumi user base "for free", as well as get all the benefits of Pulumi's great software engineering fundamentals applied to their platforms. This builds on the existing support for bridging Terraform providers for use in Pulumi, to now supporting the concept of Local Packages, which can be generated and used locally without the need to author, build and publish to the Pulumi Registry. This massively lowers the barrier to entry to use an existing Terraform/OpenTofu provider. It's also a new building block for many other places we expect to open up access to use additional open ecosystems from within Pulumi over the coming months. Check out more in the blog post: https://www.pulumi.com/blog/any-terraform-provider/
9
partypus 8bit 13
❤️ 6
a
This is awesome!
i
Hello! I wonder what place Pulumi has now for all bridged providers. As I can see from the article, the new feature generates the SDK right in the folder with my code. The main question I have for now is how am I supposed to spread such packages inside my company. We have one bridged provider. Yes, we have to maintain it, build it, and store plugin binaries and the SDK package in our artifact repository (we use Nexus). But we have a rather convenient way for developers to use them. We just need a one-time change for package.json (or requirements.txt) to point to the SDK library, and everything else is fully automated.
npm install && pulumi pre
and you are ready to go. For this new approach, I wonder what we should do: 1. Should we add the 'sdk' folder to .gitignore? But every new developer must do the proper
pulumi package add
command. 2. Should we store the generated SDK right into the repository? But we have many repositories - so it's not very DRY. Our bridged provider is rather big and has much code - so it looks like too much boilerplate. 3. What about the plugin part of the provider (the binary part)? Where is it stored? Is it also built on the developer's machine? But this leads to inconsistency - everybody is using different unique binaries 😃 In the end, the main questions are: 1. Should we get rid of the bridged provider in favor of this new way of building one? 2. How do we suppose to spread it across the company (how to make it a proper artifact dependency for everybody to reuse)?
w
Big step forward for Pulumi!
pulumi logo 1
👍 1
e
@incalculable-notebook-65772 1. No, the expectation is these SDKs would just be committed to the git repository so other users of the repo just get access to it without having to rerun
package add
3. There is no separate built plugin for dynamically bridged providers like this. They all use the same one binary which is the "pulumi-provider-terraform-provider" plugin 4. Maybe. Bridged providers are still supported, and support more things then the dynamic bridge currently supports (like being able to specify renames of properties). Use which ever one works better and easier for your specific use case. 2/5. We're working on making this better, but you can just use the existing
pulumi package gen-sdk
command for these new dynamic bridged packages to just get an SDK library which you can then push to artifactory or similar. Again there's no separate plugin for these so you just need to distribute the SDK.
👍 1
m
How do you use import command using these local providers ? I have tested that on the netlify terraform provider, guessed that the type of resource I wanted to import was netlifyindex/siteBuildSettingsSiteBuildSettings and got an error message "failed to validate provider config: could not find latest version for provider netlify:"
e
We're working that out still. The UI isn't designed around the extra parameters that these providers need to specify them at the moment, but I think the ImportID resource option should work as normal. If there are bugs with that raise issues about it and we'll take a look.
m
Ok I created an issue 👉 https://github.com/pulumi/pulumi-terraform-provider/issues/35. By the way, what is the proper command to update a local provider ?