Closed matttrach closed 4 years ago
@matttrach Can you provide your op
version alongside a snippet of the Terraform that generated this output?
I do not have a one password client installed in the container, is that necessary?
No, the client should be automatically downloaded and unzipped into /tmp/
if it can't find it in the container. Looks like version 0.7.1 which is a few releases behind.
Although I'm not convinced that that's what is causing the race. I'd love to try to recreate the issue on my side. Do you just have a data.onepassword_item_secure_note
resource or is there more going on in your Terraform installation?
There is quite a bit more, I am also using the JIRA, Openstack, and GitLab plugins. The provisioner plugins should not interfere with each other though, right?
That sounds similar to my company setup 😄 GitHub, PagerDuty, Datadog, and Aviatrix.
It's highly unlikely for them to interfere with each other as they execute in separate processes. That said, I have been able to cause Terraform to crash (in general, not provider specific) by having a large number of modules that depend on outputs from other modules.
e.g.
module/resource
module/dependent
module/dependent
module/dependent
module/dependent
module/dependent
x100
In those situations my team has to apply -target module.resource
before the dependent
modules will stop crashing the plan.
Does this sound similar at all to your situation? I hope it helps!
We have less than 30 modules overall, I don't think that is causing any problems.
I figured it out, I have 2FA enabled for 1pass, since the 2FA is unable to send the message and 1pass is in a waiting pattern for the 2FA approval there is a loop. I was able to bypass by logging in manually using the CLI, which sets the OP_SESSION env variable and everything worked as expected.
Thanks for explaining the problem to us. I think I can close this issue if you have any more question, please create new one issue or re-open this.
This happens during
terraform plan
in 'ubuntu:bionic' container.