We’re excited to announce a new and improved Terra...
# announcements
m
We’re excited to announce a new and improved Terraform converter, now available to use via the
pulumi convert --from terraform
command in v3.71.0 of the Pulumi CLI. It can convert whole Terraform projects, including Terraform modules. Read more about it at https://www.pulumi.com/blog/converting-full-terraform-programs-to-pulumi/
s
Really glad to see this. Solid Terraform conversion is a big win, hope you can continue to improve this
e
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.
m
Does anyone else get an error using the example from the blog?
Copy code
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
e
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.
m
To be clear, I ran:
Copy code
git clone <https://github.com/avantoss/vault-infra.git>
cd vault-infra/terraform/main
pulumi convert --from terraform --language typescript --out pulumi
e
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.
m
Okay, sounds good, ping me when you'd like me to give it a shot!
e
1.0.2 is released, but provider blocks are still giving it some issues. Continuing to work on that and hopefully have something soon!
m
Copy code
error: could not generate output program: no resource plugin 'pulumi-resource-std' found in the workspace or on your $PATH
e
Are you on the most recent CLI release? I think that was fixed very recently
m
Copy code
❯ pulumi version
v3.70.0
e
Try 3.71
m
That is interesting, usually I get nagged to upgrade immediately
I still have issues with
3.71.0
Copy code
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: conversion failed
but that's probably what you're working on
e
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.
And 1.0.3 is now released and no longer errors on that vault-infra example. It will warn and drop a TODO in the Pulumi.yaml for the aws:region but it shouldn't error out anymore.
m
Confirmed it works now with TypeScript. Bummer that YAML isn't supported yet.
Also, in a real world project, it's blowing up on properties I wouldn't expect, e.g.
default_tags
and
ebsBlockDevice
e
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
s
@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?
e
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.
s
A summary here would be great while a blog is pending ...
e
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.
s
Thanks, that's a really helpful summary!
Minor Q: is the state import from the default Terraform workspace supported, i.e. when not explicitly using workspace feature? We don't use TF Cloud / Enterprise and I'm not a fan of the non-cloudy TF workspace feature
e
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.
s
understood, thanks!