This message was deleted.

Here are some social links for sharing/engaging further: • Twitter: https://twitter.com/PulumiCorp/status/1668346876293177357 • LinkedIn: https://www.linkedin.com/posts/pulumi_converting-full-terraform-programs-to-pulumi-activity-7074113401462927360-g80r/?utm_source=share&utm_medium=member_desktop

Really glad to see this. Solid Terraform conversion is a big win, hope you can continue to improve this

hope you can continue to improve this

We will! While we've phrased this as bringing "tf2pulumi" into the CLI it's actually a complete rewrite of the Terraform conversion code to take full advantage of CrossCode. It should be much easier for us to fix issues and support new features. Plus we'll be spending significant effort in the coming months improving the stability and functionality of CrossCode itself.

Does anyone else get an error using the example from the blog?

error: /Users/catmeme/dev/vendor/pulumi/vault-infra/terraform/main/providers.tf:5,12-15: Variables not allowed; Variables may not be used here.
error: /Users/catmeme/dev/vendor/pulumi/vault-infra/terraform/main/providers.tf:4,1-15: Failed to evaluate provider config; Failed to evaluate provider config for aws:region
error: load project: could not validate '/var/folders/5w/46p_zz3x3kd6j46cbsj7x6bh0000gn/T/pulumi-convert352646147/Pulumi.yaml': 3 errors occurred:
	* #/runtime: oneOf failed
	* #/runtime: length must be >= 1, but got 0
	* #/runtime: expected object, but got string

Ah I think that's because you have some provider configuration, support for that was put in very last minute and I'm continuing to work on it today.

To be clear, I ran:

git clone <https://github.com/avantoss/vault-infra.git>
cd vault-infra/terraform/main
pulumi convert --from terraform --language typescript --out pulumi

Can probably get a new converter release done today with a fix for that, updating should be as simple as running "pulumi plugin install converter terraform" once the new release happens.

Okay, sounds good, ping me when you'd like me to give it a shot!

1.0.2 is released, but provider blocks are still giving it some issues. Continuing to work on that and hopefully have something soon!

Are you on the most recent CLI release? I think that was fixed very recently

Try 3.71

That is interesting, usually I get nagged to upgrade immediately

Yup that's what I'm working on 🙂 Hope to have 1.0.3 with a fix for that soon. We wrote the blog post using v0.0.12 I think, which didn't try to convert provider blocks and so missed these errors.

Confirmed it works now with TypeScript. Bummer that YAML isn't supported yet.

If you raise issues about those at https://github.com/pulumi/pulumi with snippets of what those properties look like we can take a look

@echoing-dinner-19531 is there a comparison of

pulumi convert

and

pulumi import

to convert TF code (and state)? Comparing to https://www.pulumi.com/docs/using-pulumi/adopting-pulumi/import/ it seems that import can generate code from TF - what are the pros / cons of the two options?

I don't think we have anything written down for that! It would make a good blog post though, especially given that one of our upcoming features (sneak previews here) is to do a pulumi import from a terraform workspace. There will still be pros and cons to each method, but we can detail that to make it easier for y'all to make decisions on which to use.

A summary here would be great while a blog is pending ...

import

doesn't understand relationships between resources, configuration, unspecified default values, or resource meta-arguments (like having three of the same resource, or having

protect

set).

convert

can understand all of the above as it gets to work directly with the markup source code that defined the resources in the first place. However the domain of

convert

is much more complicated than import and you are more likely to hit issues with it where it can't work out how to correctly translate things.

import

is a very simple "read the data, emit a single code block to set the data", so its much less likely to fail or emit something incorrect. Finally if you already have resources created you have to use

import

in some capacity to bring them into pulumi state. You might still want to use

convert

first to get a good program for it, and then just use

import

to get state and throw away it's codegen. If you don't have resources created then you can't use

import

because it depends on actual resource data read from the cloud api, but you can still use

convert

. And as I said above, we're looking at adding a way to take a terraform workspace and use

convert

to translate it's markup to a pulumi program, and then

import

to import it's state. So the best results will come from using both commands together.

Thanks, that's a really helpful summary!

The plan is to support importing from any terraform state store to pulumi. But just to make it clear those are future feature we're working on, nothings yet released for this.

understood, thanks!