https://pantsbuild.org/ logo
Join Slack
Powered by
Hey I have recently started using pants terraform ...
# general
r
Hey I have recently started using pants terraform plugin and I am wondering what goes inside this config https://www.pantsbuild.org/2.18/reference/targets/terraform_deployment#backend_config Is it path to backend config file, or i need to provide key,value pair?
normally i run terraform init as follows
Copy code
terraform init --backend-config=vars/backend.conf
what would be the eqauivalent of this using the 
terraform_deployment
target
c
in 2.18 and 2.19, that's the name of the file backend file. Terraform support is still in development (and got a rework after 2.19), let me know how it's working out for you!
r
thanks @careful-address-89803 It worked out well when the deployment is done from scratch using pants.
But if the statefile already exists, i mean deployment was done outside pants, I get an error called:
Copy code
Error: error loading state: unsupported checkable object kind "var"
Maybe its because of older terraform version used by pants. Is there a way where we can specify which terraform version to be used by pants.
c
Is there a way where we can specify which terraform version to be used by pants.
yes, see: https://www.pantsbuild.org/2.18/reference/subsystems/download-terraform
r
thanks @curved-television-6568 For suggestion. I used that option to specify version 1.7.2 which I already installed on my system using brew. But pants is giving me this error:
Copy code
UnknownVersion: No known version of terraform 1.7.2 for macos_x86_64 found in ('1.4.6|macos_
c
Have also updated the known versions option?
r
Just looking into that . What goes inside that Looking at that looks like 
<version>|<name>|<sha256sum>|<?>
Copy code
1.4.6|macos_x86_64|5d8332994b86411b049391d31ad1a0785dfb470db8b9c50617de28ddb5d1f25d|22051279
So how do we get the 
name
is it anything we can provide or you have some predefined name or naming schems? Whats the very last part 
<?>
?
c
ah, we're a bit behind on that. see this MR for the values: https://github.com/pantsbuild/pants/pull/20469/files
r
thanks @careful-address-89803. I am able to install 1.7.1 now using the values from the MR.
also upgrading to newer version now solves the error that i was getting earlier related to statefiles
but have another issue now, justchanged something in backed config and now getting this error
Copy code
:29:06.28 [INFO] pantsd started
00:29:06.63 [INFO] Initializing scheduler...
00:29:12.41 [INFO] Scheduler initialized.
00:29:17.72 [INFO] Deploying targets...
╷
│ Error: Backend initialization required, please run "terraform init"
│
│ Reason: Initial configuration of the requested backend "s3"
│
│ The "backend" is the interface that Terraform uses to store state,
│ perform operations, etc. If this message is showing up, it means that the
│ Terraform configuration you're using is using a custom configuration for
│ the Terraform backend.
│
│ Changes to backend configurations require reinitialization. This allows
│ Terraform to set up the new configuration, copy existing state, etc. Please run
│ "terraform init" with either the "-reconfigure" or "-migrate-state" flags to
│ use the current configuration.
│
│ If the change reason above is incorrect, please verify your configuration
│ hasn't changed and try again. At this point, no changes to your existing
│ configuration or state have been made.
╵

✕ terraform/environments:staging failed
not sure how to pass args to terraform init using pants
c
Ah, sorry about that. I think Pants is swallowing an error in initialising with a backend, which is why it's uninitialised later. I think that's because the backend requires external tools. Can you try this workaround https://github.com/pantsbuild/pants/issues/20363#issuecomment-1885844876 ?
r
@careful-address-89803 its not swallowing any error. Its show what the actual error. My backend config has actually changed and I need to reinitialize 
terraform init -reconfigure
command
but not sure how to make pants pass 
-reconfigure
arugment to terraform init
c
Ah, ok, that makes sense. Unfortunately, there isn't a way to pass extra args to the 
init
process. I thought there was, but they're only passed to the 
apply
process. I think you'd need to manually run the upgrade, and then Pants should use the migrated state. the TF backend runs 
init
and then 
apply
. Seeing 'please run "terraform init"' and 'Initial configuration of the requested backend "s3"' made me think that 
init
had failed, Pants swallowed the error, and then the deployment wasn't initialised. Another reason I'm concerned that's the case is that the TF backend doesn't keep a persistent initialised ".terraform" directory, so it shouldn't have a backend that needs to be reconfigured (although I've never used the s3 backend). you could check with 
pants check
on the root module of the deployment, as that runs 
terraform init -backend=false
which might show an init error. you migth also run it with 
keep-sandboxes=always
which should keep the Pants sandbox around. You could then open it and manually edit the command. But that seems like a lot more work
Also, can you help me understand when someone would need 
-reconfigure
or 
-migrate-state
? I don't think I've used either of them
r
Basically if after first deployment with terraform if we change any configuration in backend then it needs to be `-reconfigure`d or if we change the backend type i.e from 
s3
to 
local
or any other backend. then we need to run 
-migrate-state
backend.
In my case I just asked backend to assume an role, after the first initialization, so I would need to reconfigure it
Since this option needs to be provided just one time after changing config, so I guess preserving the sandbox option works. We run it one time manually and then on subsequent runs we can let pants run terraform init and other cmds same as earlier.
c
Thanks for that information. I don't think I've changed the backend before. From reading the doc I thought it would only affect reinitialisation (or using an initialised module). I'll need to experiment with that a bit. It should be easy to allow passing extra arguments to the init process. I could do the work for that or it would make a good first issue 🙂 . You also probably don't need to keep the sandboxes. Pants is just calling Terraform, and you could probably run the Terraform commands you normally would to migrate it.
r
Anyways, Running the terraform init from inside sandbox with required args worked and now for subsequent runs its running without any issues. Thanks for the help!
c
I'm glad we got it working in the end! Also, thanks for sharing your usecase.
r
Hi @careful-address-89803 That requirement of passing args to 
terraform init
command is popping up again. Basically on local it was solved by keeping the sandbox and then manually running terraform command with required args. But since this propblem is occuring in CI pipeline i.e github action. There is no way to keep the sandbox and run this command manually there. So far I have tried to look into this. There is an option to pass args via environment variable. https://developer.hashicorp.com/terraform/cli/config/environment-variables#tf_cli_args-and-tf_cli_args_name. I am able to use this option on local. But its not helping me in CI. So for now looks like passing extra args through pants is the only option. let me know if there is workaround in pants for this. So far have looked in to 
terraform_download
subsystem, 
terraform_deployment
target and 
experimental-deploy
goal. Nothing helpful found or I at least I am not able to find it.
Screenshot 2024-02-12 at 12.43.29 PM.png
c
Passing cli args via envvars is neat. I'm not sure why 
[download_terraform].extra_env_vars
would work locally but not in CI. There currently isn't a way to pass extra cli args to the terraform 
init
invocation. You should be able to run the terraform commands directly still.
I didn't have time to implement passing args to the init process, but it should be simple enough. Let me know if you're interested in implementing that, I can walk you through it.
r
Yes, I am interested to implement that.
c
It shouldn't be too many steps: 1. add an option on 
TerraformTool
, called something like 
extra_init_args
, similar to 
args
here. I think you'll have to set 
passthrough
to false, I'm pretty sure there can be only 1 passthrough option. 2. request the 
TerraformTool
in 
get_terraform_providers
here. There's an example of how to do that here 3. add the value of the option to the args, like here I hope that helps! If you'd like more guidance or help you can ping me, either here on in direct messages
2 Views
Open in Slack
PreviousNext
Powered by